From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: Scott Long <scott_long@adaptec.com>,
linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Proposed Enhancements to MD
Date: Tue, 13 Jan 2004 11:19:47 -0700 [thread overview]
Message-ID: <400436C3.6050507@backtobasicsmgmt.com> (raw)
In-Reply-To: <20040113081932.A721@lists.us.dell.com>
Matt Domsch wrote:
> DDF is quickly becoming important to RAID and system vendors, and I
> welcome Adaptec's work to implement DDF support on Linux.
Fully agreed, the days of vendor-specific metadata formats need to be
numbered (with a small number). Speaking a customer with a CMD
FC-to-SCSI RAID controller, which used to be dual-redundant but is now
single (because of a dead unit), we are not looking forward to the day
when the remaining controller dies and we lose all the data on the array
due to a forced metadata format change.
However, given that this will not likely be 2.6 material until after
it's built and tested in 2.7 and then backported, it doesn't seem to
make any sense to me to build any of this on top of the MD subsystem at
all (see other replies about using DM instead). Additionally, it also
does not seem to make any sense to build any of the DDF
reading/writing/management in the kernel _at all_. There is no advantage
to it being there once initramfs is a standard part of the boot process,
so all of this should be done is userspace and just communicated into
the kernel to tell it what logical devices to construct using which DM
modules.
next prev parent reply other threads:[~2004-01-13 18:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 3:41 Proposed Enhancements to MD Scott Long
2004-01-13 10:24 ` 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 [this message]
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
[not found] <40033D02.8000207@adaptec.com>
2004-01-13 18:44 ` Proposed enhancements " 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-14 23:07 ` Neil Brown
2004-01-15 11:10 ` Norman Schmidt
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
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=400436C3.6050507@backtobasicsmgmt.com \
--to=kpfleming@backtobasicsmgmt.com \
--cc=Matt_Domsch@dell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).