[dm-devel] mirroring: [patch 5 of 6] device failure tolerance

[Jonathan E Brassow]

On Jun 30, 2005, at 1:10 PM, Jonathan E Brassow wrote:

>
> On Jun 30, 2005, at 12:56 PM, Alasdair G Kergon wrote:
>
>> On Thu, Jun 30, 2005 at 11:38:28AM -0500, Kevin Corry wrote:
>>> Any time a target's table-format or status-format changes, we also 
>>> need to
>>> increment that target's version number so user-space can figure out 
>>> which
>>> format to expect.
>>
>> Indeed, but I don't want version numbers updating till we know what
>> sequence things will go upstream.
>>
>> BTW I've not seen a justification for breaking the existing format 
>> here
>> yet as opposed to simply appending new data to the end of the status 
>> line.
>>
>
> mirror_status first calls the log status function and then adds on to 
> that.  If we want to do what you are proposing, we would move the log 
> status function _after_ the DMEMIT's for mirror and it would only 
> print out a char for each log device indicating status.  We would have 
> to remember that STATUSTYPE_INFO and STATUSTYPE_TABLE would call the 
> log status function at different place (one after it's own DMEMITs, 
> the other before).
>

Perhaps like the attached patch.

I think the pvmove stuff is already busted.  How does it handle mirrors 
with more than 2 sides?  (ok, so pvmove isn't broken, but code that 
uses the same function to determine a mirrors status would be - lvs?)  
If we are going to add code that must correctly handle the number of 
mirror args, I think we could add code to properly handle the log args 
at the same time.  Then we have some (limited) flexibility in how 
things are handled.

  brassow

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00005-alt.patch
Type: application/octet-stream
Size: 1882 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20050630/f0c34f13/attachment.obj>
-------------- next part --------------