On Fri, Oct 05, 2007 at 08:52:17AM +0100, Robert Milkowski wrote:
> Hello Eric,
> 
> Thursday, October 4, 2007, 5:54:06 PM, you wrote:
> 
> ES> On Thu, Oct 04, 2007 at 05:22:58AM -0700, Ivan Wang wrote:
> >> > This bug was rendered moot via 6528732 in build
> >> > snv_68 (and s10_u5).  We
> >> > now store physical devices paths with the vnodes, so
> >> > even though the
> >> > SATA framework doesn't correctly support open by
> >> > devid in early boot, we
> >> 
> >> But if I read it right, there is still a problem in SATA framework 
> >> (failing ldi_open_by_devid,) right?
> >> If this problem is framework-wide, it might just bite back some time in 
> >> the future.
> >> 
> 
> ES> Yes, there is still a bug in the SATA framework, in that
> ES> ldi_open_by_devid() doesn't work early in boot.  Opening by device path
> ES> works so long as you don't recable your boot devices.  If we had open by
> ES> devid working in early boot, then this wouldn't be a problem.
> 
> Even if someone re-cables sata disks couldn't we fallback to "read zfs
> label from all available disks and find our pool and import it"?

FreeBSD's GEOM storage framework implements a method called 'taste'.
When new disks arrives (or is closed after last write), GEOM calls taste
methods of all storage subsystems and subsystems can try to read their
metadata. This is bascially how autoconfiguration happens in FreeBSD for
things like software RAID1/RAID3/stripe/and others.
It's much easier than what ZFS does:
1. read /etc/zfs/zpool.cache
2. open components by name
3. if there is no such disk goto 5
4. verify diskid (not all disks have an ID)
5. if diskid doesn't match, try to lookup by ID

If there are few hundreds of disks, it may slows booting down, but it
was never a real problem in FreeBSD.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
[EMAIL PROTECTED]                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Attachment: pgpnSvy49Vtnr.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to