Re: RFC - new raid superblock layout for md driver

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

 



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-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux