All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Slow Write Performance w/ No Cache Enabled and Different Size Drives
Date: Wed, 23 Apr 2014 03:18:34 +0000 (UTC)	[thread overview]
Message-ID: <pan$d444b$cef389d2$82cdb021$b6eb95b4@cox.net> (raw)
In-Reply-To: BDB8ED64-0A92-4C22-A07D-C06D790410ED@colorremedies.com

Chris Murphy posted on Tue, 22 Apr 2014 11:42:09 -0600 as excerpted:


> On Apr 21, 2014, at 3:09 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Adam Brenner posted on Sun, 20 Apr 2014 21:56:10 -0700 as excerpted:
>> 
>>> So ... BTRFS at this point in time, does not actually "stripe" the
>>> data across N number of devices/blocks for aggregated performance
>>> increase (both read and write)?
>> 
>> What Chris says is correct, but just in case it's unclear as written,
>> let me try a reworded version, perhaps addressing a few uncaught
>> details in the process.
> 
> Another likely problem is terminology. It's 2014 and still we don't have
> consistency in basic RAID terminology.

> It's not immediately obvious to the btrfs newcomer that the md raid
> chunk isn't the same thing as the btrfs chunk, for example.
> 
> And strip, chunk, stripe unit, and stripe size get used interchangeably
> to mean the same thing, while just as often stripe size means something
> different.

FWIW, I did hesitate at one point, then used "stripe" for what I guess 
should have been strip or stripe-unit, after considering and rejecting 
"chunk" as already in use.

But in any case, while btrfs single mode is distinct from btrfs raid0 
mode, and because the minimum single-mode unit is 1 GiB and thus too 
large to do practical raid0, on multiple devices btrfs single mode does 
in fact end up in a sort of raid0 layout, just with too big a "strip" to 
work as raid0 in practice.

IOW, btrfs single mode layout is one 1 GiB chunk on one device at a time, 
but btrfs will alternate devices with those 1 GiB chunks (choosing the 
one with the least usage from those available), *NOT* use one device 
until it's full, then another until its full, etc, like md/raid linear 
mode does.  In that way, the layout is raid0-like, even if the chunks are 
too big to be practical raid0.

Btrfs raid0 mode, however, *DOES* work as raid0 in practice.  It still 
allocates 1 GiB chunks per devices, but does so in parallel across all 
available devices, and then stripes at a unit far smaller than the 1 GiB 
chunk, using I believe a 64 or 128 KiB strip/stripe-unit/whatever, with 
the full stripe-size thus being that times the number of devices in 
parallel in the stripe.

<sigh>  It's all clear in my head, anyway! =:^(

-- 
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


      parent reply	other threads:[~2014-04-23  3:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-20 17:27 Slow Write Performance w/ No Cache Enabled and Different Size Drives Adam Brenner
2014-04-20 20:54 ` Chris Murphy
2014-04-20 21:04   ` Chris Murphy
2014-04-21  4:56   ` Adam Brenner
2014-04-21  5:32     ` Chris Murphy
2014-04-21 21:09     ` Duncan
2014-04-22 17:42       ` Chris Murphy
2014-04-22 17:56         ` Hugo Mills
2014-04-22 18:41           ` Chris Murphy
2014-04-23  3:18         ` Duncan [this message]

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$d444b$cef389d2$82cdb021$b6eb95b4@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.