[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Improving dm-mirror as a final year project

On Feb 14, 2011, at 11:33 AM, Miklos Vajna wrote:

On Tue, Feb 01, 2011 at 10:12:36AM -0600, Jonathan Brassow <jbrassow redhat com > wrote:
I do not yet have the right to send those patches (I do this in
university time, so the copyright is not mine), but I hope to be
able to
do so - to get them reviewed.


I'm attaching the two patches. I tested these on RHEL5, but I don't
think there are major changes in newer versions, either.

If that's the only problem, I can test it on latest linux-2.6.git.

Any feedback is welcome. :)

Thanks for the patches. I've seen the first one before (slightly different) - I'll discuss it with others whether to include in rhel5. There is no read-balancing in rhel6/upstream.

The second patch addresses which device should be primary. This can be done when creating the mirror. I'm not sure how much benefit there is to doing this additional step. Most people will access dm mirrors through LVM - not through the dm message interface. If it makes sense upstream - and you can argue for it - though, I would consider it.

Wether changes are going into rhel5 or rhel6, we still like it when they go upstream first. We generally don't like feature inversion.

If you have any interest in dm-raid, these are some of the things that need to be done: 1) Definition of new MD superblock: Some of this is started, and I've got a working version, but I'm sure there are pieces missing related to offsets that must be tracked for RAID type conversion, etc. 2) Bitmap work: The bitmap keeps track of which areas of the array are being written. Right now, I take all the bitmap code "as-is". There are a number of things in this area to be improved. Firstly, we don't necessarily need all the fields in the bitmap superblock - perhaps this could be streamlined and added to the new MD superblock. Secondly, things are way too slow. I get a 10x slowdown when using a bitmap with RAID1 through device-mapper. This could be due to the region-size chosen, the bitmap being at a stupid offset, or something else. This problem could be solved by trial-and-error or through profiling and reason... seems like a great small project. 3) Conversion code: New device-mapper targets (very simple small ones) must be written to engage the MD RAID conversion code (like when you change RAID4 to RAID5, for example)
4) Failure testing
5) LVM code: to handle creation of RAID devices
6) dmeventd code: to handle device failures

This is an incomplete list, but does have a variety of complexity and duration.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]