[dm-devel] [PATCH v2] DM RAID: Add support for MD RAID10

[Brassow Jonathan]

On Jul 16, 2012, at 3:28 AM, keld at keldix.com wrote:

>> 
>> Maybe you are suggesting that dmraid should not support raid10-far or
>> raid10-offset until the "new" approach is implemented.
> 
> I don't know. It may take a while to get it implemented as long as no seasoned 
> kernel hackers are working on it. As it is implemented now by Barrow, why not then go
> forward as planned. 
> 
> For the offset layout I don't have a good idea on how to improve the redundancy.
> Maybe you or others have good ideas. Or is the offset layout an implementation
> of a standard layout? Then there is not much ado. Except if we could find a layout that has
> the same advantages but with better redundancy.

Excuse me, s/Barrow/Brassow/ - my parents insist.

I've got a "simple" idea for improving the redundancy of the "far" algorithms.  Right now, when calculating the device on which the far copy will go, we perform:
	d += geo->near_copies;
	d %= geo->raid_disks;
This effectively "shifts" the copy rows over by 'near_copies' (1 in the simple case), as follows:
	disk1	disk2	or	disk1	disk2	disk3
	=====	=====		=====	=====	=====
	 A1	 A2		 A1	 A2	 A3
	 ..	 ..		 ..	 ..	 ..
	 A2	 A1		 A3	 A1	 A2
For all odd numbers of 'far' copies, this is what we should do.  However, for an even number of far copies, we should shift "near_copies + 1" - unless (far_copies == (raid_disks / near_copies)), in which case it should be simply "near_copies".  This should provide maximum redundancy for all cases, I think.  I will call the number of devices the copy is shifted the "device stride", or dev_stride.  Here are a couple examples:
	2-devices, near=1, far=2, offset=0/1: dev_stride = nc (SAME AS CURRENT ALGORITHM)

	3-devices, near=1, far=2, offset=0/1: dev_stride = nc + 1.  Layout changes as follows:
	disk1	disk2	disk3
	=====	=====	=====
	 A1	 A2	 A3
	 ..	 ..	 ..
	 A2	 A3	 A1

	4-devices, near=1, far=2, offset=0/1: dev_stride = nc + 1.  Layout changes as follows:
	disk1	disk2	disk3	disk4
	=====	=====	=====   =====
	 A1	 A2	 A3	 A4
	 ..	 ..	 ..	 ..
	 A3	 A4	 A1	 A2
This gives max redundancy for 3, 4, 5, etc far copies too, as long as each stripe that's copied is laid down at: 	d += geo->dev_stride * copy#;  (where far=2, copy# would be 0 and 1.  Far=3, copy# would be 0, 1, 2).
Here's a couple more quick examples to make that clear:
	3-devices, near=1, far=3, offset=0/1: dev_stride = nc (SHOULD BE SAME AS CURRENT)
	disk1	disk2	disk3
	=====	=====	=====
	 A1	 A2	 A3
	 ..	 ..	 ..
	 A3	 A1	 A2
	 ..	 ..	 ..
	 A2	 A3	 A1  -- Each copy "shifted" 'nc' from the last
	 ..	 ..	 ..

	5-devices, near=1, far=4, offset=0/1: dev_stride = nc + 1.  Layout changes to:
	disk1	disk2	disk3	disk4	disk5
	=====	=====	=====   =====	=====
	 A1	 A2	 A3	 A4	 A5
	 ..	 ..	 ..	 ..	 ..
	 A4	 A5	 A1	 A2	 A3
	 ..	 ..	 ..	 ..	 ..
	 A2	 A3	 A4	 A5	 A1  -- Each copy "shifted" (nc + 1) from the last
	 ..	 ..	 ..	 ..	 ..
	 A5	 A1	 A2	 A3	 A4
	 ..	 ..	 ..	 ..	 ..

This should require a new bit in 'layout' (bit 17) to signify a different calculation in the way the copy device selection happens.  We then need to replace 'd += geo->near_copies' with 'd += geo->dev_stride' and set dev_stride in 'setup_geo'.  I'm not certain how much work it is beyond that, but I don't *think* it looks that bad and I'd be happy to do it.

So, should I allow the current "far" and "offset" in dm-raid, or should I simply allow "near" for now?

 brassow