From: NeilBrown <neilb@suse.com>
To: Anthony Youngman <antlists@youngman.org.uk>,
linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Wiki, raid 10, and my new system :-)
Date: Wed, 18 Oct 2017 07:14:06 +1100 [thread overview]
Message-ID: <87bml5jzw1.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <67a81e49-37b6-b0f7-f9e2-16301ecd4f9a@youngman.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
On Tue, Oct 17 2017, Anthony Youngman wrote:
> On 17/10/17 01:33, NeilBrown wrote:
>> On Mon, Oct 16 2017, Reindl Harald wrote:
>>
>>> Am 16.10.2017 um 15:54 schrieb Wols Lists:
>>>> Raid 10 is a complicated subject what with near and far, and whether it
>>>> will grow, etc etc.
>>>>
>>>> I'm planning to raid-10 my swap partition, and while it doesn't matter
>>>> in the slightest because destroying and recreating will be no hassle for
>>>> swap, I'd like to understand what's going on.
>>>>
>>>> If I remember correctly, there was a thread a little while back on
>>>> growing a raid-10? And you can't (for certain values of "can't" :-) do it?
>>>>
>>>> Where's the best place to find info about near, far and offset layouts?
>>>
>>> http://xmodulo.com/setup-raid10-linux.html
>>
>> This patch has some good stuff, but
>>
>> Chunk Size, as per the Linux RAID wiki, is the smallest unit of data
>> that can be written to the devices
>>
>> I wonder where the Linux RAID wiki say that. It is wrong.
>> The smallest unit of data that can be written to the devices is the
>> block size, which is hardware dependant and typically 512bytes or 4K.
>> This is not the same as the chunk size.
>>
> https://raid.wiki.kernel.org/index.php/RAID_setup#Chunk_sizes
>
> I understand what it's saying - this is the smallest size passed down to
> the disk, not the smallest size that the disk can write ... :-)
Well that is wrong too. It is not the smallest size passed down to the
disk. That is also 512b or 4K. Maybe it is the largest size that might
be passed down to a single disk.
It is the granularity at which the address-space of the array is divided
up before being shared around the address space of the member devices.
It has (almost) nothing to do with the size of IO requests.
NeilBrown
>
> This page has made it into the archaeology section so I don't plan to
> update it. And in context, it's reasonably clear what it means.
>
> Cheers,
> Wol
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-10-17 20:14 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
2017-10-17 21:01 ` NeilBrown
2017-10-17 20:14 ` NeilBrown [this message]
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=87bml5jzw1.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=antlists@youngman.org.uk \
--cc=linux-raid@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).