ZFS - hot spares : automatic or not?

Alexander Leidinger Alexander at Leidinger.net
Thu Jan 13 15:02:41 UTC 2011


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  
too).

> 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.

Bye,
Alexander.

-- 
Whatever creates the greatest inconvenience for the largest
number must happen.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the freebsd-stable mailing list