Solved Partitions corrupted after ZFS export?

David Bryan

New Member

Messages: 2

(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:

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:

=>        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:

=>        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]


Beastie's Twin

Reaction score: 1,856
Messages: 6,318

zpool create -f backups ada4

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)

David Bryan

New Member

Messages: 2

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.


New Member

Reaction score: 7
Messages: 15

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.