From: Phil Turmel <philip@turmel.org>
To: Anthony Youngman <antlists@youngman.org.uk>,
NeilBrown <neilb@suse.com>,
linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Wiki, raid 10, and my new system :-)
Date: Tue, 17 Oct 2017 16:57:14 -0400 [thread overview]
Message-ID: <9cfedac1-aaa2-a53d-4ece-97a63ecfb355@turmel.org> (raw)
In-Reply-To: <0c360057-f616-dcee-5f0a-59e12cb6ab43@youngman.org.uk>
On 10/17/2017 04:43 PM, Anthony Youngman wrote:
> On 17/10/17 20:04, Phil Turmel wrote:
>> No, it is*wrong*. Writes in multiples of 4k and entirely within a
>> chunk are passes as-is to the devices. For mirrors, all affected
>> devices get a copy of the request. For parity raid, the 4k stripes
>> corresponding to those 4k blocks will be pulled into the stripe cache
>> for recalculation. Not whole chunk-size stripes. The stripe cache is
>> multiples of 4k, not multiples of the chunk size!
>>
>> Writes smaller than 4k, or not aligned to 4k, will generate a
>> read-modify-write cycle of the 4k block involved. Not the whole chunk.
>>
>> It is more accurate to say that a chunk may be the*largest* a request
>> can be before it is split between devices.
>
> Okay, I think I need to update my understanding on this ... :-)
>
> Let's say a chunk is 12K. That's three 4K blocks to drive 1, followed by
> three to drive 2 etc. Does that mean that each chunk is split across
> three stripes, or is the stripe all the 12K chunks one per drive?
A stripe is still a chunk on each driver. You are confusing the chunk
as part of the layout with the read/write operations on the underlying
devices. Read/write operations to the array obviously have to be split
at chunk boundaries because that's where the layout divides the
underlying space between devices. But *within* a single chunk, the
operation simply passes through (plus mirrors or write recalc as
needed). Minimum-size operations on underlying devices are 4k.
> In other words, does a stripe consist of one block per drive, or one
> chunk per drive?
The *stripe* is one chunk per drive.
But the stripe *cache* is one block per drive per cache entry, because
operations on devices are multiples of blocks, not chunks.
> (I'll put a "sic" on that page then, just to point out it's a
> misunderstanding by the original author. As I said, I'd rather not mess
> around with the page now.)
The number one pitch point for wikis is that they can be edited, and the
wiki keeps a history. I don't get why you don't want to fix it.
{ But then, I'm not really a fan of wikis .... }
Phil
next prev parent reply other threads:[~2017-10-17 20:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 13:54 Wiki, raid 10, and my new system :-) Wols Lists
2017-10-16 14:26 ` Reindl Harald
2017-10-17 0:33 ` NeilBrown
2017-10-17 18:32 ` Anthony Youngman
2017-10-17 19:04 ` Phil Turmel
2017-10-17 20:43 ` Anthony Youngman
2017-10-17 20:57 ` Phil Turmel [this message]
2017-10-17 21:01 ` NeilBrown
2017-10-17 20:14 ` NeilBrown
2017-10-17 0:42 ` NeilBrown
2017-10-20 0:55 ` Wols Lists
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=9cfedac1-aaa2-a53d-4ece-97a63ecfb355@turmel.org \
--to=philip@turmel.org \
--cc=antlists@youngman.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.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).