Re: Degraded raid handling

Heinz Mauelshagen <[email protected]>
Newsgroups gmane.linux.ataraid
Message-ID <[email protected]>
On Wed, May 16, 2007 at 11:50:15AM -0400, Phillip Susi wrote:
> Heinz Mauelshagen wrote:
> >Those are defined to cover states for a 'broken' set (i.e. 
> >non-recoverable),
> >'inconsistent' (i.e. recoverable), 'nosync' (i.e. set has to be resolvered,
> >'ok' (i.e. set is fully synced and devices accessible) and 'setup', which 
> >is
> >an interim state during metadata setup, hence transition will go from 
> >'setup'
> >to any of the others when the sets metadata got fully discovered and 
> >grouped.
> 
> Specifically what is the difference between nosync and inconsistent?  Is 
> it that with the former both disks in the mirror are online and working, 
> but have not been resynced yet, and with the latter only one disk is 
> online so you need to replace the failed one?

For e.g., yes.

> 
> 
> >No, if the RAID set is out of sync it needs to be synced, which is what
> >the 'sync' parameter means.
> >
> >Those are handled by the dirty log (dm-log.c), not by any dm target 
> >directly.
> 
> I see.. so it is telling dm that it should begin copying all data from 
> the primary mirror to the other(s), yes?

Yes, unless you've got more information which part of the set
needs resynchronization, which ATARAIDs typically don't provide.

> 
> >>Further, I can not see anywhere the s_inconsistent or 
> >>s_nosync flags ever can be set on the raid set.  What gives?
> >
> >The fact, that a dmeventd DSO still needs implementing in order to make
> >use of those. Such DSO will handle device evvent based state changes
> >and reated ondisk metadata updates (e.g. replacement of a broken drive
> >by a spare one).
> 
> Don't they also need to be used at boot?  If you go to assemble a mirror 
> and one disk is missing, shouldn't the state of the set be 
> s_inconsistent?  I can't see that the current code does this.

Sure. The current code tries activating degraded mirrors with a
linear mapping. If that needs enhancement, please send patches.

> 
> Also is there some documentation I can read somewhere on this dmeventd 
> design?  I don't understand it.

Look at the code and inline doc in libdevmapper.
The idea is, that applications can register devices with dmeventd
and dmeventd calls into an application specific DSO, when a device
event occurs (i.e. device IO error). The DSO code can react on such events
by e.g. reconfiguring a mirror.

> 
> >Use "dmraid -r -c... device-path".
> 
> I don't think this will do what I need it to.  This will just read the 
> metadata of the disk and report if that metadata says the set is ok or 
> inconsistent.  Presumably it will say it is ok because up until now it 
> has been, but now we can't find the second disk to build the set so the 
> state of the set needs changed to inconsistent.

Well, you gotta find 2 drives for the mirror; if you only
discover one you can react on it.

> 
> What I need is a way ask dmraid to try and build the set, but fail ( and 
> indicate so ) if it would have to activate the set as inconsistent. 
> That way the system can wait a while and try again, in the hope that the 
> missing disk will show up.

dmraid -tay ?

> 
> If the mirror IS activated by dmraid with one disk missing, does dmraid 
> update the metadata to indicate that the set is inconsistent?

Not yet. You'ld need to use the BIOS management util to do that for now.

> And will 
> that not require manual intervention to restore the second disk?

Yes, see last point.

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Storage Development                               56242 Marienrachdorf
                                                  Germany
[email protected]                            PHONE +49  171 7803392
                                                  FAX   +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.