On Fri, Mar 23, 2007 at 11:31:03AM +0100, Pawel Jakub Dawidek wrote: > On Thu, Mar 22, 2007 at 08:39:55AM -0700, Eric Schrock wrote: > > Again, thanks to devids, the autoreplace code would not kick in here at > > all. You would end up with an identical pool. > > 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
s/can/can't/ > 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". -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgpMjTSvCwNLk.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
