Error GEOM_MIRROR from FreeBSD 9.0-CURRENT-201011

[nagual2]

I have problems from GEOM_MIRROR in GEOM_MIRROR. I've lost all slices from initialised gmirror.
I boot from da0 end install my system to da1.

umount /mnt
gpart delete -i 3 da1
gpart delete -i 2 da1
gpart delete -i 1 da1
gpart destroy da1

gpart create -s GPT da1
gpart add -b 34 -s 256 -t freebsd-boot -l boot0 da1
gpart add -b 290 -s 30G -t freebsd-ufs -l disk0 da1
gpart add -b 62914850 -t freebsd-swap -l swap0 da1
gpart bootcode -b /boot/pmbr da1
gpart bootcode -p /boot/gptboot -i 1 da1

newfs -O2 -U /dev/da1
tunefs -j enable /dev/da1
mount /dev/da1 /mnt

cd /; pax -p eme -X -rw . /mnt
cd /var; pax -p eme -X -rw . /mnt/var
cd /usr; pax -p eme -X -rw . /mnt/usr

Now all ok.

 echo 'geom_mirror_load=YES' >> /boot/loader.conf 
kldload geom_mirror
sysctl kern.geom.debugflags=16
gmirror label -v -b round-robin gm0 /dev/da1

Now lost all slice from da1!
I reinstall all.

gpart create -s GPT mirror/gm0
gpart add -b 34 -s 256 -t freebsd-boot -l boot0 mirror/gm0
gpart add -b 290 -s 30G -t freebsd-ufs -l disk0 mirror/gm0
gpart add -b 62914850 -t freebsd-swap -l swap0 mirror/gm0
gpart bootcode -b /boot/pmbr mirror/gm0
gpart bootcode -p /boot/gptboot -i 1 mirror/gm0

newfs -O2 -U /dev/mirror/gm0p2
tunefs -j enable /dev/mirror/gm0p2
mount /dev/mirror/gm0p2 /mnt

cd /; pax -p eme -X -rw . /mnt
cd /var; pax -p eme -X -rw . /mnt/var
cd /usr; pax -p eme -X -rw . /mnt/usr

From reboot kernel panic.
After reboot first messages:

gptboot: invalid backup gtp header

Array degraded:

Dec 13 17:04:18 xeon kernel: GEOM_MIRROR: Device mirror/gm0 launched (1/2).
Dec 13 17:04:18 xeon kernel: GEOM_MIRROR: Device gm0: rebuilding provider da0.
Dec 13 17:04:18 xeon kernel: Trying to mount root from ufs:/dev/mirror/gm0p2 [rw]...
Dec 13 17:21:48 xeon kernel: GEOM_MIRROR: Device gm0: rebuilding provider da0 finished.

What problems? tunefs -j enable & GEOM_MIRROR not work?

Ather informations:

uname -a
FreeBSD xeon 9.0-CURRENT-201011 FreeBSD 9.0-CURRENT-201011 #0: Wed Nov  3 18:19:06 UTC 2010     
[email]root@obrian.cse.buffalo.edu[/email]:/usr/obj/usr/src/sys/GENERIC  i386

ahd0: <Adaptec AIC7902 Ultra320 SCSI adapter> port 0x4400-0x44ff,0x4000-0x40ff mem 0xfc400000-0xfc401fff irq 76 at device 2.0 on pci6
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs
ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter> port 0x4c00-0x4cff,0x4800-0x48ff mem 0xfc402000-0xfc403fff irq 77 at device 2.1 on pci6

da0 at ahd0 bus 0 scbus0 target 0 lun 0
da0: <IBM IC35L036UCDY10-0 S27Q> Fixed Direct Access SCSI-3 device
da0: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit)
da0: Command Queueing enabled
da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C)
da1 at ahd0 bus 0 scbus0 target 1 lun 0
da1: <IBM IC35L036UCDY10-0 S23C> Fixed Direct Access SCSI-3 device
da1: 320.000MB/s transfers (160.000MHz DT, offset 127, 16bit)
da1: Command Queueing enabled

diskinfo -v da0
da0
        512             # sectorsize
        36703918080     # mediasize in bytes (34G)
        71687340        # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        4462            # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.

 

[kpa]

You're mixing GPT partitions and full disk gmirror, such combination does not work too well because both GPT and gmirror are fighting over the last sector of the disk. Change to mirroring the individual partitions or use MBR partitioning.

 

[wblock@]

To expand on that:

GPT puts a backup partition table at the end of the disk, and only at the end of the disk.[1]
GEOM_MIRROR and other GEOM things put metadata at the end of the allocated area. If a whole disk, this overwrites the GPT backup partition table.

End result: GEOM_stuff can go inside GPT partitions. GPT cannot safely go inside GEOM-allocated areas, even whole disks.[2]


1: GPT behavior is not a bug, it's from the GPT specification.
2: GEOM *should* only overwrite the GPT backup table, but the GPT bootloader complains and other GPT things will be unhappy. Ordinary data *should* be safe, but there's little reason to take the risk.