On Feb 14, 2011, at 11:33 AM, Miklos Vajna wrote:
On Tue, Feb 01, 2011 at 10:12:36AM -0600, Jonathan Brassow <jbrassow@xxxxxxxxxx
> 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.
Hi,
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.
brassow
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
