Re: RFC - new raid superblock layout for md driver

[Steven Dake <sdake@mvista.com>]

Doug,

EVMS integrates all of this stuff together into one cohesive peice of 
technology.

But I agree, LVM should be modified to support RAID 1 and RAID 5, or MD 
should be modified to support volume management.  Since RAID 1 and RAID 
5 are easier to implement, LVM is probably the best place to put all 
this stuff.

Doug Ledford wrote:

>On Thu, Nov 21, 2002 at 11:34:24AM -0800, Joel Becker wrote:
>  
>
>>On Wed, Nov 20, 2002 at 08:46:25PM -0500, Doug Ledford wrote:
>>    
>>
>>>I haven't yet played with the new dm code, but if it's like I expect it to 
>>>be, then I predict that in a few years, or maybe much less, md and dm will 
>>>be two parts of the same whole.  The purpose of md is to map from a single 
>>>      
>>>
>>	Most LVMs support mirroring as an essential function.  They
>>don't usually support RAID5, leaving that to hardware.
>>	I certainly don't want to have to deal with two disparate
>>systems to get my code up and running.  I don't want to be limited in my
>>mirroring options at the block device level.
>>	DM supports mirroring.  It's a simple 1:2 map.  Imagine this LVM
>>volume layout, where volume 1 is data and mirrored, and volume 2 is some
>>scratch space crossing both disks.
>>
>>	[Disk 1]	[Disk 2]
>>	  [volume 1]	  [volume 1 copy]
>>          [       volume 2              ]
>>	
>>	If DM handles the mirroring, this works great.  Disk 1 and disk
>>2 are handled either as the whole disk (sd[ab]) or one big partition on
>>each disk (sd[ab]1), with DM handling the sizing and layout, even
>>dynamically.
>>	If MD is handling this, then the disks have to be partitioned.
>>sd[ab]1 contain the portions of md0, and sd[ab]2 are managed by DM.  I
>>can't resize the partitions on the fly, I can't break the mirror to add
>>space to volume 2 quickly, etc.
>>    
>>
>
>Not at all.  That was the point of me entire email, that the LVM code 
>should handle these types of shuffles of space and simply use md modules 
>as the underlying mapper technology.  Then, you go to one place to both 
>specify how things are laid out and what mapping is used in those laid out 
>spaces.  Basically, I'm saying how I think things *should* be, and you're 
>telling me how they *are*.  I know this, and I'm saying how things *are* 
>is wrong.  There *should* be no md superblocks, there should only be dm 
>superblocks on LVM physical devices and those DM superblocks should 
>include the data needed to fire up the proper md module on the proper 
>physical extents based upon what mapper technology is specified in the 
>DM superblock and what layout is specified in the DM superblock.  In my 
>opinion, the existence of both an MD and DM driver is wrong because they 
>are inherently two sides of the same coin, logical device mapping support, 
>with one being better at putting physical disks into intelligent arrays 
>and one being better at mapping different logical volumes onto one or more 
>physical volume groups.
>
>  
>