linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Scott Long <scott_long@adaptec.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>, linux-raid@vger.kernel.org
Subject: Re: DDF Trial Use draft specification now publicly available
Date: Fri, 12 Mar 2004 16:07:22 -0500	[thread overview]
Message-ID: <4052268A.2000806@pobox.com> (raw)
In-Reply-To: <4051667A.5010303@adaptec.com>

Scott Long wrote:
> Complexity != brokenness

Agreed, but complexity is also something that is one of the key things 
to resist...  Favorite Linus maxims include "don't overdesign" and "do 
what you need to do, and no more"  ;-)


> Recording information about all disks and arrays on every disk means
> that you can detect when a whole array is missing.  The more complex
> array information means that you can express mutli-level arrays in a
> reasonable way.  We've already spoken a little bit about this.  There is

I think you're missing an overall point about scope.  DDF configuration 
is not global, from the standpoint of a Linux system.  md's 
configuration (raidtab, etc) is.

Therefore, from the standpoint from the entire Linux system, the 
definition "all disks and arrays" varies from one RAID "domain" to another.

This artificial partitioning into domains is obviously required for 
hardware RAID -- a single controller does not know anything more than 
what spindles are attached to it.

But...  this partitioning, the _initialization and ordering of domains_, 
varies from controller to controller, and sometimes AFAICS from one 
setup to setup.  The Linux kernel now has to organize all that into a 
coherent picture.

"Getting RAID domains right" is where I see a lot of complexity...  The 
simplicity of md's raidtab provides the same thing in userspace -- just 
list the ordering in a text file.  The kernel only really cares about 
auto-running the RAID upon which your root filesystem (and raidtab) lives.


> also quite a bit of information in the format that allows you to
> validate each disk and determine how much your 'trust' it.  While this
> certainly adds complexity, it also strengthens the notion that RAID is
> about ensuring integrety.  Of course it doesn't slow down the actual
> transform of a raid-0, so you can still measure it's worthiness that
> way =-)

Yeah, the basic r/w fast path isn't too tough, it's not only  error 
handling but also the minute variations in RAID formats where things 
gets fun :)


> As Matt Domsch mentioned earlier, Adaptec has been working on a DDF
> implementation for Linux under MD.  We are putting the final touches on
> it right now (as I type this at 12:30am) and getting it ready for formal
> testing.  After that, we will release it to the Linux community for
> review and inclusion.  As an added benefit, our Enhanced MD will also
> provide full (and Open) support for Adaptec HostRAID.

Yep, looking forward to it :)

	Jeff





  reply	other threads:[~2004-03-12 21:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-11 15:45 DDF Trial Use draft specification now publicly available Matt Domsch
2004-03-11 16:08 ` Samuel Davidoff
2004-03-11 16:18   ` Matt Domsch
2004-03-11 20:43 ` Jeff Garzik
2004-03-12  7:27   ` Scott Long
2004-03-12 21:07     ` Jeff Garzik [this message]
2004-03-12 22:27       ` Scott Long
2004-03-11 22:07 ` Jeff Garzik
2004-03-12  7:55   ` Scott Long

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=4052268A.2000806@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=Matt_Domsch@dell.com \
    --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).