Solved Partitions corrupted after ZFS export?

D

David Bryan

(First post, so hopefully I get my formats right here...)

I've been using a very old Open Solaris system with ZFS in a purely offline application for a few years. I moved to a new FreeBSD system (10.3-RELEASE-p4) a few weeks ago. Things are going very well, except for odd behavior with my backups. I have a removable drive, which I stream the file systems to. The backup works perfectly, can be exported, imported, etc., and is perfectly readable. However, there is some very odd behavior.

I created the volume by first destroying the old partitions (this drive was in a Mac before), then creating the new pool:

gpart destroy -F ada4
gpart create -s GPT ada4
zpool create -f backups ada4

I then used zfs send and recv to make the backup. It worked perfectly. I scrubbed it, exported it, checked it on another machine, all great. When I reinstalled the drive, however, I got the following dmseg:

Code: 
GEOM: ada4: the primary GPT table is corrupt or invalid.
GEOM: ada4: using the secondary instead -- recovery strongly advised.
GEOM: diskid/DISK-WD-WCC4E5CP1DPH: the primary GPT table is corrupt or invalid.
GEOM: diskid/DISK-WD-WCC4E5CP1DPH: using the secondary instead -- recovery strongly advised.

Remounted, it looked fine. Scrub was fine, so I ran:

gpart recover ada4

All was well. gpart show -l ada4 returns:

Code: 
=>        34  7814034988  ada4  GPT  (3.6T)
          34  7814034988        - free -  (3.6T)

and life is good. (although off that it says "free" instead of ZFS, which I suspect is where I'm missing a step) No further dmesg. Then I exported, and the error returned. gpart show -l ada4 gives:

Code: 
=>        34  7814034988  ada4  GPT  (3.6T) [CORRUPT]
          34  7814034988        - free -  (3.6T)

I can repair with recover. But as soon as I export, the corrupt shows again.

I tried with 2 other (different) disks and see similar behavior. The drives are different models, but are all WD Green drives...although I've done these operations quickly enough after a boot I doubt this is some power issue.

Supermicro X10SL7-F. The drives are connected to the regular SATA (not SAS) connectors, as is the root partition (which is not showing this issue). The pool that I am actually backing up is on the built-in SAS (2308, reflashed to IT mode), and not showing it either (although I haven't exported it, to be fair).

Everything is working, it's just very...disconcerting. Especially for a backup.

Any ideas?[/code][/code]
 
Code: 
zpool create -f backups ada4
Click to expand...

Don't do that, you're now writing the ZFS labels on the raw disk and that conflicts with the GPT partitioning. What you should be doing instead is:

gpart create -s GPT ada4
gpart add -a 4096 -t freebsd-zfs ada4
(the -a 4096 option is to guarantee 4k alignment in case the disk is of "advanced format" with 4k sectors but reports only 512 byte sectors)
zpool create backups ada4p1
(no -f needed, the need to use such options should be red flags that you're doing something really wrong)
 
Yes, thanks, this was the missing step. I tried it and it worked well.

It felt like I was missing a step of actually creating a partition, but was thrown off by comparing the output of gpart show with similar output from a good backup drive from the old Solaris box (which, now thinking back on it, appears to have raw disks, without partitions, for whatever reason).

Again, thanks.
 
The recommendations from Sun (Oracle) on Solaris was to use raw disks, not partitions, so that's probably how/why you saw it done that way on your Solaris machines.

This is not the case on FreeBSD, however. It is perfectly fine to use partitions for ZFS.
 
You must log in or register to reply here.
Back
Top