Re: [zfs-discuss] Re: Proposal: ZFS hotplug support and autoconfiguration
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 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! pgpm6A6Tnggir.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Proposal: ZFS hotplug support and autoconfiguration
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
Re: [zfs-discuss] Re: Proposal: ZFS hotplug support and autoconfiguration
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
Re: [zfs-discuss] Re: Proposal: ZFS hotplug support and autoconfiguration
On Wed, Mar 21, 2007 at 11:57:42PM -0700, Matt B wrote: Literally, someone should be able to make $7/hr with a stack of drives and the ability to just look or listen to a server to determin which drive needs to be replaced. This means ZFS will need to be able to control the HDD Status lights on the chassis for look, but for listen ZFS could cause the server to beep using one beep for the first slot, two beeps in rapid successions, for the second slot. A sort of lame Morse code...no device integration on ZFS's part required This is part of ongoing work with Solaris platform integration (see my last blog post) and future ZFS/FMA work. We will eventually be leveraging IPMI and SES to manage physical indicators (i.e. LEDs) in response to Solaris events. It will take some time to reach this point, however. - 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
