public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: chris.mason@oracle.com
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: RAID[56] status
Date: Thu, 06 Aug 2009 11:17:13 +0100	[thread overview]
Message-ID: <1249553833.568.23.camel@macbook.infradead.org> (raw)

If we've abandoned the idea of putting the number of redundant blocks
into the top bits of the type bitmask (and I hope we have), then we're
fairly much there. Current code is at:

   git://, http://git.infradead.org/users/dwmw2/btrfs-raid56.git
   git://, http://git.infradead.org/users/dwmw2/btrfs-progs-raid56.git=20

We have recovery working, as well as both full-stripe writes and a
temporary hack to allow smaller writes to work (with the 'write hole'
problem, of course). The main thing we need to do is ensure that we
_always_ do full-stripe writes, and then we can ditch the partial write
support.

I want to do a few other things, but AFAICT none of that needs to delay
the merge:

  - Better rebuild support -- if we lose a disk and add a replacement,
    we want to recreate only the contents of that disk, rather than
    allocating a new chunk elsewhere and then rewriting _everything_.
=20
  - Support for more than 2 redundant blocks per stripe (RAID[789] or
    RAID6[=C2=B3=E2=81=B4=E2=81=B5] or whatever we'll call it).

  - RAID[56789]0 support.

  - Clean up the discard support to do the right thing.

--=20
David Woodhouse                            Open Source Technology Centr=
e
David.Woodhouse@intel.com                              Intel Corporatio=
n

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2009-08-06 10:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 10:17 David Woodhouse [this message]
2009-08-07  9:43 ` RAID[56] status Roy Sigurd Karlsbakk
2009-08-07 15:22   ` David Woodhouse
2009-09-02 16:32     ` [PATCH] don't OOPs when we are not raid56 jim owens
2009-09-08  9:15       ` David Woodhouse
2009-09-08 13:48         ` Chris Mason
2009-11-10 19:51 ` RAID[56] status Dan Williams
2009-11-10 20:05   ` Tomasz Torcz
2009-11-10 20:11   ` Chris Mason
2009-11-10 21:06   ` tsuraan
2009-11-10 21:20     ` Gregory Maxwell

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=1249553833.568.23.camel@macbook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@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