All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Slow Write Performance w/ No Cache Enabled and Different Size Drives
Date: Tue, 22 Apr 2014 18:56:19 +0100	[thread overview]
Message-ID: <20140422175619.GC30423@carfax.org.uk> (raw)
In-Reply-To: <BDB8ED64-0A92-4C22-A07D-C06D790410ED@colorremedies.com>

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

On Tue, Apr 22, 2014 at 11:42:09AM -0600, Chris Murphy wrote:
> 
> 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. We're functionally in the 19th century uncoordinated disagreement of weights and measures, except maybe worse because we sometimes have multiple words that mean the same thing; as if there were multiple words for the term gram or meter. It's just nonsensical and selfish that this continues to persist across various file system projects.
> 
> 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. The best definition I've found so far is IBM's stripe unit definition: "granularity at which data is stored on one drive of the array before subsequent data is stored on the next drive of the array" which is in bytes. So that's the smallest raid unit we find on a drive, therefore it is a base unit in RAID, and yet we have no agreement on what word to use.
> 
> And it's not really like the storage industry trade association, SNIA, who published a dictionary of terms in 2013, really helps in this area. I'll argue they make it worse because they deprecate the term chunk, in favor of the terms strip and stripe element. NO kidding, two terms mean the same thing. Yet strip and stripe are NOT the same thing.
> 
> strip = stripe element
> stripe = set of strips
> strip size = stripe depth
> stripe size = strip size * extents not including parity extents
> 
> Also the units are in blocks (sectors, not fs blocks and not bytes). The terms stripe unit, stripe width, and stride aren't found in the SNIA dictionary at all although they are found as terms in other file system projects.
> 
> So no matter how we look at it, everyone else is doing it wrong.

   Also not helped by btrfs's co-option of the term "RAID-1" to mean
something that's not traditional RAID-1, and (internally) "stripe" and
"chunk" to mean things that don't match (I think) any of the
definitions above...

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
        --- A clear conscience.  Where did you get this taste ---        
                         for luxuries,  Bernard?                         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2014-04-22 17:56 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 [this message]
2014-04-22 18:41           ` Chris Murphy
2014-04-23  3:18         ` 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=20140422175619.GC30423@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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 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.