From: Doug Ledford <dledford@redhat.com>
To: Joel Becker <Joel.Becker@oracle.com>
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: RFC - new raid superblock layout for md driver
Date: Thu, 21 Nov 2002 14:54:06 -0500 [thread overview]
Message-ID: <20021121195406.GF14063@redhat.com> (raw)
In-Reply-To: <20021121193424.GB770@nic1-pc.us.oracle.com>
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.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
next prev parent reply other threads:[~2002-11-21 19:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-20 4:09 RFC - new raid superblock layout for md driver Neil Brown
2002-11-20 10:03 ` Anton Altaparmakov
2002-11-20 23:02 ` Neil Brown
2002-11-22 0:08 ` Kenneth D. Merry
2002-12-09 3:52 ` Neil Brown
2002-12-09 23:50 ` large await discrepancies Joe Pruett
2002-12-10 15:59 ` Joe Pruett
2002-12-12 15:30 ` Joe Pruett
2002-12-10 6:28 ` RFC - new raid superblock layout for md driver Kenneth D. Merry
2002-12-11 0:07 ` Neil Brown
2002-11-20 13:58 ` Bill Rugolsky Jr.
2002-11-20 23:17 ` Neil Brown
2002-11-20 14:09 ` Alan Cox
2002-11-20 23:11 ` Neil Brown
2002-11-21 0:30 ` Alan Cox
2002-11-21 0:10 ` John Adams
2002-11-21 0:30 ` Alan Cox
2002-11-20 16:03 ` Joel Becker
2002-11-20 23:31 ` Neil Brown
2002-11-21 1:46 ` Doug Ledford
2002-11-21 19:34 ` Joel Becker
2002-11-21 19:54 ` Doug Ledford [this message]
2002-11-21 19:57 ` Steven Dake
2002-11-21 20:38 ` Doug Ledford
2002-11-21 20:49 ` Steven Dake
2002-11-21 20:35 ` Kevin Corry
2002-11-21 21:29 ` Alan Cox
2002-11-21 21:22 ` Doug Ledford
2002-11-21 20:53 ` Kevin Corry
2002-11-21 21:55 ` Doug Ledford
2002-11-21 23:49 ` DM vs MD (Was: RFC - new raid superblock layout for md driver) Luca Berra
2002-11-21 20:06 ` RFC - new raid superblock layout for md driver Joel Becker
2002-11-21 23:35 ` Luca Berra
2002-11-22 10:13 ` Joe Thornber
2002-12-02 21:38 ` Neil Brown
2002-12-03 8:24 ` Luca Berra
2002-11-20 17:05 ` Steven Dake
2002-11-20 23:30 ` Lars Marowsky-Bree
2002-11-20 23:48 ` Neil Brown
2002-11-21 0:29 ` Steven Dake
2002-11-21 15:23 ` John Stoffel
2002-11-21 19:36 ` Joel Becker
2002-11-22 7:11 ` Jeremy Fitzhardinge
-- strict thread matches above, loose matches on Subject: below --
2002-11-20 15:55 Steve Pratt
2002-11-20 23:24 ` Neil Brown
2002-11-20 23:47 Lars Marowsky-Bree
2002-11-21 0:31 ` Neil Brown
2002-11-21 0:35 ` Steven Dake
2002-11-21 1:10 ` Alan Cox
2002-12-08 22:35 ` Neil Brown
2002-11-21 19:39 ` Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021121195406.GF14063@redhat.com \
--to=dledford@redhat.com \
--cc=Joel.Becker@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).