Re: Degraded raid handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
Mauelshagen@xxxxxxxxxx                            PHONE +49  171 7803392
                                                  FAX   +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

_______________________________________________
Ataraid-list mailing list
Ataraid-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ataraid-list

[Index of Archives]     [Linux RAID]     [Linux Device Mapper]     [Linux IDE]     [Linux SCSI]     [Kernel]     [Linux Books]     [Linux Admin]     [GFS]     [RPM]     [Yosemite Campgrounds]     [AMD 64]

  Powered by Linux