ZFS and reordering drives

Pawel Jakub Dawidek pjd at FreeBSD.org
Sun Dec 6 12:26:12 UTC 2009


On Sat, Dec 05, 2009 at 07:25:56PM -0700, Josh Carter wrote:
> FWIW, I've hit drive re-ordering problems several times on FreeBSD and OpenSolaris (most of those due to me doing abusive things to the system on purpose). In all cases a "zfs export [pool]" and "zfs import [pool]" fixed the issue. I'm not sure exactly what ZFS is doing, but even across reboots it appears to remember the configuration it used to see, and insist on seeing it again. An export/import forces ZFS to forget what it knows and look at what's on the drives.

The history of how ZFS on FreeBSD handles drives reordering is a bit
long, but to make it short it now does the following:

Search component by its name and guid stored in metadata. If guid
doesn't match or there is no such device, go through all devices (GEOM
providers) in the system and find one with matching guid.

This should work this way for a long time now, but there was a small
bug, which I fixed yesterday, where guid wasn't checked if name matched.

It should work fine now in HEAD.

In my opinion in Solaris it is less reliable now than it is in FreeBSD.
When Solaris cannot find device by name it tries by its serial number.
FreeBSD did that too in the past, but not all devices have serial
numbers and sometimes it is hard to tell serial number (what serial
number does partition have?). That's why when FreeBSD finds out that
device under remembered name has different guid, etc. it will read all
devices in the system. This is of course is more expensive than
searching by serial number, but this happens were rarely (how often
device names change?), so it is better to use more expensive, but more
reliable mechanism.

When pool is imported in the system, ZFS stores some info about it in
/boot/zfs/zpool.cache file (components names too), so after reboot it
can quickly decide which pools are imported and which GEOM providers are
part of those pools. If there are problems with stored components names,
it will fallback to expensive search as described above.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20091206/ea8c80ff/attachment.pgp


More information about the freebsd-fs mailing list