[dm-devel] Desynchronizing dm-raid1

Mikulas Patocka mpatocka at redhat.com
Mon Apr 7 23:31:19 UTC 2008


On Wed, 2 Apr 2008, malahal at us.ibm.com wrote:

> Mikulas Patocka [mpatocka at redhat.com] wrote:
>> Ideas how to fix it:
>>
>> 1. lock the buffers and unmap the pages while they are being written.
>> --- upstream developers would likely reject it. No other driver than
>> dm-raid1 has problems with this and they wouldn't damp performance because
>> of one driver.
>
> Very few drivers require it, so how about an interface to lock the pages
> of an I/O available to drivers.

Two rules of locking (one for RAID and the other for non-RAID) would 
create many bugs.

> Only needed RAID drivers would lock the
> I/O while it is in progress and they only pay the performance penalty.
> mmap pages are a bit tricky. They need to go into read-only mode when an
> I/O is in progress. I know this would likely be rejected too!!!
>
>> 4. make more region states.
>> --- If the region is in RH_DIRTY state and all writes drain, the state is
>> changed to RH_MAYBE_DIRTY. (we don't know if the region is synchronized or
>> not). The disk dirty flag is kept.
>> --- periodically (once in few minutes, so that it doesn't affect
>> performance much), the change all regions in RH_MAYBE_DIRTY state to
>> RH_CLEAN_CANDIDATE, then issue sync() on all filesystems. If, after the
>> sync(), the region is still in RH_CLEAN_CANDIDATE (i.e. it hasn't been
>> written during the sync()), it is moved to RH_CLEAN state and the on-disk
>> bit for the region is turned off.
>
> Sounds good except that it uses sync()! Is there a way to sync only
> pages related to a certain block device? How hard it is to implement
> such an interface?

No, because the dirty pages may be everywhere. I.e. on filesystem you 
create loopback device with lvm2 devices with another filesystem, 
containing another loopback ... etc.

You'd need to build a DAG of dependent devices in the kernel and there is 
no such graph currently.

If you do sync() once 15 minutes or so, I think it wouldn't have 
performance impact.

Mikulas

> --Malahal.




More information about the dm-devel mailing list