On Wed, 2 Apr 2008, malahal@xxxxxxxxxx wrote:
Mikulas Patocka [mpatocka@xxxxxxxxxx] 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.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
