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
