ZFS - hot spares : automatic or not?
spawk at acm.poly.edu
Thu Jan 13 15:07:28 UTC 2011
On 01/13/11 09:42, Alexander Leidinger wrote:
> Quoting Boris Kochergin <spawk at acm.poly.edu> (from Wed, 12 Jan 2011
> 19:50:41 -0500):
>> On 01/12/11 19:32, Chris Forgeron wrote:
>>> Solaris runs a separate process called Fault Management Daemon (fmd)
>>> that looks to handle this logic - This means that it's really not
>>> inside the ZFS code to handle this, and FreeBSD would need something
>>> similar, hopefully less kludgy than a user script.
>>> I wonder if anyone has been eyeing the fma code in the cddl with a
>>> thought for porting it - It looks to be a really neat bit of code -
>>> I'm still quite new with it, having only been working with Solaris
>>> the last few months.
> It depends upon a lot of standardized kernel notifications. Basically
> (big picture view) it is the same as our devd (reacting to events)
> with some logig what to do with it (which we can do without our devd
>> Would the people with custom hot-spare scripts, or nothing automated
>> at all, be content if the sysutils/geomWatch program grew support for
>> hot spares in a future version? I already became somewhat familiar
>> with the userland ZFS API when I added ZFS support to it.
> I had a look at geomWatch and it seems it is polling based. For
> something like zfs hotspare replacement you normally want to have the
> reaction event based (= devd). I even go further and think that things
> which geomWatch is doing, should be done with devd (may it be
> directly, or by delegating some events via a non-existing-yet
> interface (which could be even script driven) to another daemon). It
> may be that this would need some more events to be produced by
> different geom parts.
> IMO it would be great if those people with hotspare-scripts would
> publish them. This way a joined effort could be initiated to come up
> with some generic way of handling this which could be included in the
> base system.
Did a little research. In at least the ZFS case, it appears that events
are available through devctl(4) and are therefore accessible through devd:
http://2007.asiabsdcon.org/papers/P16-paper.pdf - section 3.7
More information about the freebsd-stable