GEOM: the primary GPT table is corrupt or invalid after RAIDZ creation

Troy Drake tdgx86 at gmail.com
Sat Jun 25 14:26:55 UTC 2011


I have recently setup a new file server with 5x 2TB Samsung 4K sector
drives in a RAIDZ array and after going through the steps of creating
GPT partitions to set the alignment a 1 MB aligned sector (block 2048)
and gnop to force 4k sectors and finally a RAIDZ array, I receive the
following warning:

GEOM: ad6: the primary GPT table is corrupt or invalid.
GEOM: ad6: using the secondary instead -- recovery strongly advised.
(Snipped, but applies to ad8, ad10, ad12, ad14 identically).

The steps I used to setup this array are as follows:
gpart create -s GPT ad6 (and to all others)
gpart add -t freebsd-zfs -b 2048 ad6 (and to all others)
gnop create -S 4086 ad6
zpool create raidz tank ad6.nop ad8 ad10 ad12 ad14
zpool export tank
gnop destroy ad6.nop
zpool import tank

Even though the pool works fine, gpart for all disks show no geometry:
gpart: No such geom: ad6. (et al.)

Now the pools status is good with no errors, however performance seems
a bit backwards to me:
#/usr/bin/time dd if=/dev/zero of=/tank/foo1 bs=2M count=10000
10000+0 records in
10000+0 records out
20971520000 bytes transferred in 66.247113 secs (316565040 bytes/sec)
       66.24 real         0.01 user        12.44 sys
# /usr/bin/time dd if=/tank/foo1 of=/dev/null bs=2M
10000+0 records in
10000+0 records out
20971520000 bytes transferred in 102.649646 secs (204301922 bytes/sec)
      102.65 real         0.00 user         5.71 sys

316 MB/sec writes and 204 MB/sec reads, I would expect it the other
way around, but this is consistent performance after running similar
dd tests many times. Writes are always faster than reads.

My main concern is reliability and the ability to import this pool
into perhaps into another OS just in case. Is the GEOM warnings about
a corrupt or invalid primary table a concern? Are the steps I'm using
best practices or is there a better way? I've searched the lists and
Google and what little I can find this seems like a verbose warning
but isn't too much to be concerned about, but these are my first 4K
sector disks on ZFS so I'm wanting to make sure before loading it up
with data. The performance of writes faster than reads makes me has me
a bit concerned though.

Interestingly, if I start over and create a nop on the slice at step 4
- (gnop create -S 4096 ad6p1.nop) ad6 will retain its valid GPT table
however the rest wont as they don't get nop'd. However that makes me
unsure that ad6 itself aligned properly, or that ad6 is aligned the
same as the rest of the disks.

Regards,
Troy


More information about the freebsd-fs mailing list