Date: Sat, 24 Jan 2009 07:17:49 -0600 (CST) From: Wes Morgan <morganw@chemikals.org> To: David Ehrmann <ehrmann@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: zfs drive keeps failing between export and import Message-ID: <alpine.BSF.2.00.0901240703270.66024@ibyngvyr.purzvxnyf.bet> In-Reply-To: <6e0e5340901240026o39eb4554u6d8eb8c00ee2adbb@mail.gmail.com> References: <6e0e5340901151158n5108ba8ct6af8fb270b10b75b@mail.gmail.com> <E1LNmxP-0003vM-Lx@dilbert.ticketswitch.com> <6e0e5340901161521t30845197s9529fb5a55dbba13@mail.gmail.com> <6e0e5340901221324o33f1e2b1l53c842ebf9dad9a8@mail.gmail.com> <alpine.BSF.2.00.0901222204440.39246@ibyngvyr.purzvxnyf.bet> <6e0e5340901240026o39eb4554u6d8eb8c00ee2adbb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Jan 2009, David Ehrmann wrote: > On Thu, Jan 22, 2009 at 8:07 PM, Wes Morgan <morganw@chemikals.org> wrote: >> On Thu, 22 Jan 2009, David Ehrmann wrote: >> >>> On Fri, Jan 16, 2009 at 3:21 PM, David Ehrmann <ehrmann@gmail.com> wrote: >>> >>> In the /dev/ad8.eli that zfs doesn't recognize, I found a 16 byte >>> string that was repeated a lot, but it was also repeated in another >>> place: the good /dev/ad10.eli (though the offsets were different). >>> The other weird thing: the good and bad /dev/ad8.eli look a lot alike: >>> one 16 byte string, then another that gets repeated, then another 16 >>> byte string randomly shows up at 0x200. >> >> The "xxx.eli" devices are the decrypted versions, aren't they? ZFS vdev >> labels and uberblocks occupy the first 512k of the device, and consist of >> virtually identical data, differing only by the GUID that the label claims >> to be and a sha256 checksum... So, decrypted, they should all be very, very >> similar. You could actually use the label from any device in a pool to >> reconstruct the label for any other device. > > Let me clarify one thing: when zfs has problems reading the device, > the data resemble the data when it's read fine, but by resemble, I > don't mean values as much as structure. The values are all wrong, but > if you overlaid hexdumps, both share repeated patterns. That makes me > think it's an encryption problem, but I haven't been able to reproduce > it with other configurations. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0901240703270.66024>