[dm-devel] DM-RAID1 data corruption

[Mikulas Patocka]

> > I would suggest that you simply get raid1 to block any write requests
> > until all drive failures have been acknowledged by userspace.
> > So you would need to differentiate between an acknowledged drive
> > failure and an unacknowledged failure.  Writes block when ever there
> > are unacknowledged failures.
> > Then you need a message that can be sent to the raid1 to acknowledge
> > the failure of a particular device.
> > 'suspend' would need to fail if there are any unacknowledged failures
> > as otherwise it would block.
> 
> As we discuss in this thread, your suggestion is quite similar to what
> malahal proposed more than one year ago.
> 
> malahal at us.ibm.com wrote:
> > > Look at this patch
> > > http://permalink.gmane.org/gmane.linux.kernel.device-mapper.devel/4973
> > >
> > > It essentially generates an uevet and waits for the user level code to
> > > act on it and send a message to unblock it.
> 
> This is a simple approach, but all write I/Os are blocked before write
> errors are processed by userspace (dmeventd). Depending on the error,
> such as timeout, the recovery procedure in userspace may take a long
> time and application sensitive to delay will have another problem.
> 
> superblock approach may solve this data corruption issue without an
> additional delay. When dm-raid1 detects a write error, it can disable
> the mirror leg quickly and ask userspace to process aftertreatment.
> 
> I would like to continue discussion how to fix this issue.
> 
> Thanks,
> Taka

The current code already blocks all i/os if the log fails. So if your 
application is sensitive for it, you have to test for it anyway.

You can write new implementation dm-raid1.2 that will have two log devices 
(just like md-raid has two superblocks) and can perform without userspace 
intervention if any of the legs or logs fail.

But it is really more like rewrite --- I think it would be easier to write 
it from scratch than to patch it over existing dm-raid1 code.

Mikulas