From: Jakob Oestergaard <jakob@unthought.net>
To: Scott Long <scott_long@adaptec.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Proposed enhancements to MD
Date: Tue, 13 Jan 2004 17:26:36 +0100 [thread overview]
Message-ID: <20040113162636.GT346@unthought.net> (raw)
In-Reply-To: <40033D02.8000207@adaptec.com>
On Mon, Jan 12, 2004 at 05:34:10PM -0700, Scott Long wrote:
> All,
>
> Adaptec has been looking at the MD driver for a foundation for their
> Open-Source software RAID stack. This will help us provide full
> and open support for current and future Adaptec RAID products (as
> opposed to the limited support through closed drivers that we have now).
Interesting...
>
> While MD is fairly functional and clean, there are a number of
> enhancements to it that we have been working on for a while and would
> like to push out to the community for review and integration. These
> include:
>
> - partition support for md devices: MD does not support the concept of
> fdisk partitions; the only way to approximate this right now is by
> creating multiple arrays on the same media. Fixing this is required
> for not only feature-completeness, but to allow our BIOS to recognise
> the partitions on an array and properly boot them as it would boot a
> normal disk.
This change is probably not going to go into 2.6.X anytime soon anyway,
so what's your thoughts on doing this "right" - getting MD moved into
DM ?
That would solve the problem, as I see it.
I'm not currently involved in either of those development efforts, but I
thought I'd bring your attention to the DM/MD issue - there was some
talk about it in the past.
Also, since DM will do on-line resizing and we want MD to do this as
well some day, I really think this is the way to be going. Getting
partition support on MD devices will solve a problem now, but for the
long run I really think MD should be a part of DM.
Anyway, that's my 0.02 Euro on that issue.
...
> - Metadata abstraction: We intend to support multiple on-disk metadata
> formats, along with the 'native MD' format. To do this, specific
> knowledge of MD on-disk structures must be abstracted out of the core
> and personalities modules.
I think this one touches the DM issue as well.
So, how about Adaptec and IBM get someone to move MD into DM, and while
you're at it, add hot resizing and hot conversion between RAID levels :)
2.7.1? ;)
Jokes aside, I'd like to hear your oppinions on this longer-term
perspective on things...
The RAID conversion/resize code for userspace exists already, and it
works except for some cases with RAID-5 and disks of non-equal size,
where it breaks horribly (fixable bug though).
/ jakob
next prev parent reply other threads:[~2004-01-13 16:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 0:34 Proposed enhancements to MD Scott Long
2004-01-13 16:26 ` Jakob Oestergaard [this message]
[not found] ` <20040113201058.GD1594@srv-lnx2600.matchmail.com>
2004-01-14 19:07 ` Jakob Oestergaard
[not found] ` <20040114194052.GK1594@srv-lnx2600.matchmail.com>
2004-01-14 21:02 ` Jakob Oestergaard
[not found] ` <20040114222447.GL1594@srv-lnx2600.matchmail.com>
2004-01-15 1:42 ` Jakob Oestergaard
2004-01-13 18:21 ` mutex
2004-01-13 19:05 ` Jeff Garzik
2004-01-13 19:30 ` mutex
2004-01-13 19:43 ` Jeff Garzik
2004-01-13 20:00 ` mutex
2004-01-13 20:44 ` Scott Long
2004-01-13 18:44 ` Jeff Garzik
2004-01-13 19:01 ` John Bradford
2004-01-13 19:41 ` Matt Domsch
2004-01-13 22:10 ` Arjan van de Ven
2004-01-16 9:31 ` Lars Marowsky-Bree
2004-01-16 9:57 ` Arjan van de Ven
2004-01-13 20:41 ` Scott Long
2004-01-13 22:33 ` Jure Pečar
2004-01-13 22:44 ` Scott Long
2004-01-13 22:56 ` viro
2004-01-14 15:52 ` Kevin Corry
2004-01-13 22:42 ` Luca Berra
2004-01-13 22:06 ` Arjan van de Ven
2004-01-13 22:44 ` Wakko Warner
2004-01-13 22:34 ` Arjan van de Ven
2004-01-13 23:09 ` Andreas Steinmetz
2004-01-13 23:38 ` Wakko Warner
2004-01-14 16:16 ` Kevin Corry
2004-01-14 16:53 ` Kevin P. Fleming
2004-01-14 23:07 ` Neil Brown
2004-01-15 21:52 ` Matt Domsch
2004-01-16 9:24 ` Lars Marowsky-Bree
2004-01-16 13:43 ` Matt Domsch
2004-01-16 13:56 ` Lars Marowsky-Bree
2004-01-16 14:06 ` Christoph Hellwig
2004-01-16 14:11 ` Matt Domsch
2004-01-16 14:13 ` Christoph Hellwig
[not found] <40036902.8080403@adaptec.com>
2004-01-13 14:19 ` Proposed Enhancements " Matt Domsch
2004-01-13 17:13 ` Andreas Dilger
2004-01-13 22:26 ` Andreas Dilger
2004-01-13 18:19 ` Kevin P. Fleming
2004-01-13 18:19 ` Jeff Garzik
2004-01-13 20:29 ` Chris Friesen
2004-01-13 20:35 ` Matt Domsch
2004-01-13 21:10 ` Matt Domsch
-- strict thread matches above, loose matches on Subject: below --
2004-01-13 19:59 Proposed enhancements " Cress, Andrew R
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=20040113162636.GT346@unthought.net \
--to=jakob@unthought.net \
--cc=linux-kernel@vger.kernel.org \
--cc=scott_long@adaptec.com \
/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