Wes Morgan wrote:
You might try creating the pool, saving the first 512k of each block
device to a file, then export the pool and repeat, then import (or try
to). Run zdb on each file and compare the output. From creation to
export to import they should only differ by the "state" in the top
level of the label nvlist. If the entire label is corrupted, then
likely it's a crypto problem.
Although, it really sounds like you've been able to eliminate zfs as a
culprit.
This is pretty much what I tried. between export, geli detach, and geli
attach, zdb -l went from reporting info on the pool to reporting that no
labels were found. dd confirmed what zdb was saying, so I have no
reason to think zfs is acting up. I just don't get why I haven't been
able to reproduce this with another zpool-less disk or two md disks.
Maybe the .eli device shows up before it's ready to use and something
gets cached by zfs in the background. Maybe it has something to do with
me using two disks. A race condition? None of these are really easy
things to find.
For now, the only two ideas I have are trying zfs on a single disk with
this configuration, and trying it on multiple disks, when the RMA is
done, with 2 disks.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
