linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Joel Becker <Joel.Becker@oracle.com>,
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: RFC - new raid superblock layout for md driver
Date: Wed, 20 Nov 2002 20:46:25 -0500	[thread overview]
Message-ID: <20021121014625.GA14063@redhat.com> (raw)
In-Reply-To: <15836.7011.785444.979392@notabene.cse.unsw.edu.au>

On Thu, Nov 21, 2002 at 10:31:47AM +1100, Neil Brown wrote:
> I see MD and DM as quite different, though I haven't looked much as DM
> so I could be wrong.

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 
logical device to all the underlying physical devices.  The purpose of :VM 
code in general is to handle the creation, orginization, and mapping of 
multiple physical devices into a single logical device.  LVM code is 
usually shy on advanced mapping routines like RAID5, relying instead on 
underlying hardware to handle things like that while the LVM code itself 
just concentrates on physical volumes in the logical volume similar to how 
linear would do things.  But, the things LVM does do that are very handy, 
are things like adding a new disk to a volume group and having the volume 
group automatically expand to fill the additional space, making it 
possible to increase the size of a logical volume on the fly.

When you get right down to it, MD is 95% advanced mapping of physical
disks with different possibilities for redundancy and performance.  DM is
95% advanced handling of logical volumes including snapshot support,
shrink/grow on the fly support, labelling, sharing, etc.  The best of both
worlds would be to make all of the MD modules be plug-ins in the DM code
so that anyone creating a logical volume from a group of physical disks
could pick which mapping they want used; linear, raid0, raid1, raid5, etc.  
You would also want all the md modules inside the DM/LVM core to support
the advanced features of LVM, with the online resizing being the primary
one that the md modules would need to implement and export an interface
for.  I would think that the snapshot support would be done at the LVM/DM
level instead of in the individual md modules.

Anyway, that's my take on how the two *should* go over the next year or 
so, who knows if that's what will actually happen.


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

  reply	other threads:[~2002-11-21  1:46 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 [this message]
2002-11-21 19:34       ` Joel Becker
2002-11-21 19:54         ` Doug Ledford
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=20021121014625.GA14063@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).