Re: Degraded raid handling
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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?
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?
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.
Also is there some documentation I can read somewhere on this dmeventd design? I don't understand it.
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.
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.
If the mirror IS activated by dmraid with one disk missing, does dmraid update the metadata to indicate that the set is inconsistent? And will that not require manual intervention to restore the second disk?
_______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list