From: Scott Long <scott_long@adaptec.com>
To: linux-raid@vger.kernel.org
Subject: Proposed Enhancements to MD
Date: Mon, 12 Jan 2004 20:41:54 -0700 [thread overview]
Message-ID: <40036902.8080403@adaptec.com> (raw)
(I already posted this to LKML a few hours ago but forgot to post it
over here)
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).
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.
- generic device arrival notification mechanism: This is needed to
support device hot-plug, and allow arrays to be automatically
configured regardless of when the md module is loaded or initialized.
RedHat EL3 has a scaled down version of this already, but it is
specific to MD and only works if MD is statically compiled into the
kernel. A general mechanism will benefit MD as well as any other
storage system that wants hot-arrival notices.
- RAID-0 fixes: The MD RAID-0 personality is unable to perform I/O
that spans a chunk boundary. Modifications are needed so that it can
take a request and break it up into 1 or more per-disk requests.
- 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.
- DDF Metadata support: Future products will use the 'DDF' on-disk
metadata scheme. These products will be bootable by the BIOS, but
must have DDF support in the OS. This will plug into the abstraction
mentioned above.
I'm going to push these changes out in phases in order to keep the risk
and churn to a minimum. The attached patch is for the partition
support. It was originally from Ingo Molnar, but has changed quite a
bit due to the radical changes in the disk/block layer in 2.6. The 2.4
version works quite well, while the 2.6 version is fairly fresh. One
problem that I have with it is that the created partitions show up in
/proc/partitions after running fdisk, but not after a reboot.
Scott
next reply other threads:[~2004-01-13 3:41 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 3:41 Scott Long [this message]
2004-01-13 10:24 ` Proposed Enhancements to MD Lars Marowsky-Bree
2004-01-13 18:03 ` Scott Long
2004-01-16 9:29 ` Lars Marowsky-Bree
2004-01-13 14:19 ` 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
2004-01-13 0:34 Scott Long
2004-01-13 16:26 ` Jakob Oestergaard
[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: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: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 11:10 ` Norman Schmidt
2004-01-15 21:52 ` Matt Domsch
2004-01-15 21:52 ` Matt Domsch
2004-01-16 9:24 ` Lars Marowsky-Bree
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:11 ` Matt Domsch
2004-01-16 14:13 ` Christoph Hellwig
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=40036902.8080403@adaptec.com \
--to=scott_long@adaptec.com \
--cc=linux-raid@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.