On Fri, Mar 23, 2007 at 11:31:03AM +0100, Pawel Jakub Dawidek wrote:
> 
> Eric, maybe I'm missing something, but why ZFS depend on devids at all?
> As I understand it, devid is something that never change for a block
> device, eg. disk serial number, but on the other hand it is optional, so
> we can rely on the fact it's always there (I mean for all block devices
> we use).
> 
> Why we simply not forget about devids and just focus on on-disk metadata
> to detect pool components?
> 
> The only reason I see is performance. This is probably why
> /etc/zfs/zpool.cache is used as well.
> 
> In FreeBSD we have the GEOM infrastructure for storage. Each storage
> device (disk, partition, mirror, etc.) is simply a GEOM provider. If
> GEOM provider appears (eg. disk is inserted, partition is configured)
> all interested parties are informed about this I can 'taste' the
> provider by reading metadata specific for them. The same when provider
> goes away - all interested parties are informed and can react
> accordingly.
> 
> We don't see any performance problems related to the fact that each disk
> that appears is read by many "GEOM classes".

We do use the on-disk metatdata for verification purposes, but we can't
open the device based on the metadata.  We don't have a corresponding
interface in Solaris, so there is no way to say "open the device with
this particular on-disk data".  The devid is also unique to the device
(it's based on manufacturer/model/serialnumber), so that we can uniquely
identify devices for fault management purposes.

The world of hotplug and device configuration in Solaris is quite
complicated.  Part of my time spent on this work has been just writing
down the existing semantics.  A scheme like that in FreeBSD would be
nice, but unlikely to appear given the existing complexity.  As part of
the I/O retire work we will likely be introducing device contracts,
which is a step in the right direction but it's a very long road.

Thanks for sharing the details on FreeBSD, it's quite interesting.
Since the majority of this work is Solaris-specific, I'll be interested
to see how other platforms deal with this type of reconfiguration.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to