From: Sanidhya Solanki <lkml.page@gmail.com>
To: Goffredo Baroncelli <kreijack@inwind.it>
Cc: Chris Murphy <lists@colorremedies.com>,
"Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs-progs: Make RAID stripesize configurable
Date: Thu, 28 Jul 2016 00:18:47 -0400 [thread overview]
Message-ID: <20160728001847.481b7e77@ad> (raw)
In-Reply-To: <e0eb3366-7183-59b1-7cdc-3debd4e45b79@inwind.it>
On Wed, 27 Jul 2016 18:25:48 +0200
Goffredo Baroncelli <kreijack@inwind.it> wrote:
> I am not able to understand this sentence: on the best of my knowledge,
> in btrfs the RAID5/RAID6 stripe is composed by several sub-stripes (I am
> not sure about the terminology to adopt); the number of sub-stripe is equal
> to the number of the disk.
>
> Until now, in btrfs the size of sub-stripe is fixed to 64k, so the size
> of a stripe is equal to 64k * <number of disks>. So for raid5 the minimum
> stripe size is 192k, for raid6 is 256k.
> Why you are writing that the real stripe size is 4kb (may be that you are
> referring to the be the page size ?).
No problem with going over the details one more time.
What I called and what was agreed to be called stripe size in the email sent
originally sent by Chris Murphy (link below) is actually how a single block
of data is laid out on disk.
This number is a component of the stripe element size (which you called the
sub-stripe). This has nothing to do with how DIFFERENT but concurrent stripes
(which you defined as 64k * <number of disk>) of data are laid out on disk.
Their relation is such that they follow the order when they are read, but are
otherwise unrelated to each other. The correct way to look at a stripe is as
follows (with its current value before this patch in brackets):
Stripe Element Size (64 KiB) =
Stripe size (1024B) * Number of elements per stripe element (64)
For the stripe code, the stripe element size matters, and for the metadata,
the stripe size matters.
The (64k * <number of disks>) is how concurrent stripes of data are distributed
across the RAID disks. The order is only important when performing an I/O
operation.
Reference email: https://www.spinics.net/lists/linux-btrfs/msg57471.html
Hope this makes it simpler.
Sanidhya
prev parent reply other threads:[~2016-07-28 4:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 13:42 [PATCH] btrfs-progs: Make RAID stripesize configurable Sanidhya Solanki
2016-07-22 14:58 ` Austin S. Hemmelgarn
2016-07-22 16:06 ` Sanidhya Solanki
2016-07-22 17:20 ` Austin S. Hemmelgarn
2016-07-26 17:14 ` Chris Murphy
2016-07-26 17:47 ` Austin S. Hemmelgarn
2016-07-27 6:12 ` Sanidhya Solanki
2016-07-27 16:25 ` Goffredo Baroncelli
2016-07-28 4:18 ` Sanidhya Solanki [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=20160728001847.481b7e77@ad \
--to=lkml.page@gmail.com \
--cc=ahferroin7@gmail.com \
--cc=kreijack@inwind.it \
--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 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).