linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid5
Date: Tue, 22 Oct 2013 13:27:44 +0000 (UTC)	[thread overview]
Message-ID: <pan$59a02$8231ca78$f5d54bfb$30812437@cox.net> (raw)
In-Reply-To: 0833228b-7a17-49f8-836a-2565a6b9af0c@aliyun.com

lilofile posted on Mon, 21 Oct 2013 23:45:58 +0800 as excerpted:

> hi:
>     since RAID 5/6 code merged into Btrfs from  2013.2, no update and
>     bug are found in maillist? is any development plan with btrfs raid5?
>     such as adjusting stripe width、 reconstruction?
>   compared to md raid5  what is advantage in btrfs raid5 ?

AFAIK, btrfs raid5/6 modes are still not considered ready for deployed 
use, only for testing (tho with each new kernel cycle I wonder if that 
has changed, but no word on it changing yet).  This is because there's a 
hole in the recovery process in case of a lost device, making it 
dangerous to use except for the pure test-case.

Yes, flushing out the features a bit is planned, tho I've not tracked 
specifics.  (My primary interest and use-case is the N-way-mirroring 
raid1 case, which is roadmapped for merging after raid5/6 stabilize; 
current "raid1" case is limited to 2-way-mirroring.  So mostly I'm simply 
tracking raid5/6 progress in relation to that, not for its own merits, 
thus I'm not personally tracking the specifics too closely.)

The advantage in btrfs raid5/6 is that unlike md/raid, btrfs knows what 
blocks are actually used by data/metadata, and can use that information 
in a rebuild/recovery situation to only sync/rebuild the actually used 
blocks on a re-added or replacement device, skipping blocks that were 
entirely unused/empty in the first place.

md/raid can't do that, because it tries to be a filesystem agnostic layer 
that doesn't know nor care what blocks on the layers above it were 
actually used or empty.  For it to try to track that would be a layering 
violation and would seriously complicate the code and/or limit usage to 
only those filesystems or other layers above that it supported/understood/
could-properly-track.

A comparable relationship exists between a ramdisk (comparable to md/
raid) and tmpfs (comparable to btrfs) -- the first is transparent and 
allows the flexibility of putting whatever filesystem or other upper 
layer on top, while the latter is the filesystem layer itself, allowing 
nothing else above it.  But the ramdisk/tmpfs case deals with memory 
emulating block device storage, while the mdraid/btrfs case deals with 
multiple block devices emulating a single device.  In both cases each has 
its purpose, with the strengths of one being the limitations of the 
other, and you choose the one that best matches your use case.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2013-10-22 13:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 15:45 btrfs raid5 lilofile
2013-10-22 13:27 ` Duncan [this message]
2013-10-22 16:00   ` David Sterba
2013-10-22 17:18   ` Alexandre Oliva
2013-10-22 17:40     ` Brendan Hide
2013-10-22 19:24       ` Alexandre Oliva
2013-10-23  0:50         ` Duncan
2013-10-26  7:21           ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2013-10-22  2:30 shuo lv
2013-10-22 13:30 ` Duncan

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='pan$59a02$8231ca78$f5d54bfb$30812437@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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;
as well as URLs for NNTP newsgroup(s).