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.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:37 EST