From: Scott Long <scott_long@adaptec.com>
To: Jeff Garzik <jgarzik@pobox.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 00:27:54 -0700 [thread overview]
Message-ID: <4051667A.5010303@adaptec.com> (raw)
In-Reply-To: <4050CF66.8090409@pobox.com>
Jeff Garzik wrote:
> Matt Domsch wrote:
> > The Disk Data Format (DDF) trial use draft spec has now been published
> > by SNIA. This is the common on-disk metadata format that
> > RAID vendors have been driving towards, which should allow one to move
> > disks from one vendor's RAID controller to another vendor's RAID
> > controller without the backup-rebuild-restore that's currently needed.
> >
> > http://www.snia.org/tech_activities/ddftwg
>
> Thanks for posting this.
>
> I haven't even read past "locality" section to find brokenness. DDF
> RAID groups (a.k.a. each RAID array) must store information about other
> RAID groups "on the controller." There is also apparently
> per-controller state information one must care about. While I
> understand why they would want this, this also means the format is quite
> a bit less flexible than md, and in some respects, more difficult to
> work with.
>
Complexity != brokenness
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
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 =-)
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.
Scott
next prev parent reply other threads:[~2004-03-12 7:27 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 [this message]
2004-03-12 21:07 ` Jeff Garzik
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=4051667A.5010303@adaptec.com \
--to=scott_long@adaptec.com \
--cc=Matt_Domsch@dell.com \
--cc=jgarzik@pobox.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 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).