From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Tomasz Torcz <tomek@pipebreaker.pl>, linux-btrfs@vger.kernel.org
Subject: Re: 1 week to rebuid 4x 3TB raid10 is a long time!
Date: Sun, 20 Jul 2014 10:50:09 -0400 [thread overview]
Message-ID: <53CBD721.2080502@gmail.com> (raw)
In-Reply-To: <20140720140044.GB7469@mother.pipebreaker.pl>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
On 07/20/2014 10:00 AM, Tomasz Torcz wrote:
> On Sun, Jul 20, 2014 at 01:53:34PM +0000, Duncan wrote:
>> TM posted on Sun, 20 Jul 2014 08:45:51 +0000 as excerpted:
>>
>>> One week for a raid10 rebuild 4x3TB drives is a very long time.
>>> Any thoughts?
>>> Can you share any statistics from your RAID10 rebuilds?
>>
>>
>> At a week, that's nearly 5 MiB per second, which isn't great, but isn't
>> entirely out of the realm of reason either, given all the processing it's
>> doing. A day would be 33.11+, reasonable thruput for a straight copy,
>> and a raid rebuild is rather more complex than a straight copy, so...
>
> Uhm, sorry, but 5MBps is _entirely_ unreasonable. It is order-of-magnitude
> unreasonable. And "all the processing" shouldn't even show as a blip
> on modern CPUs.
> This "speed" is undefendable.
>
I wholly agree that it's undefendable, but I can tell you why it is so
slow, it's not 'all the processing' (which is maybe a few hundred
instructions on x86 for each block), it's because BTRFS still serializes
writes to devices, instead of queuing all of them in parallel (that is,
when there are four devices that need written to, it writes to each one
in sequence, waiting for the previous write to finish before dispatching
the next write). Personally, I would love to see this behavior
improved, but I really don't have any time to work on it myself.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]
next prev parent reply other threads:[~2014-07-20 14:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-20 8:45 1 week to rebuid 4x 3TB raid10 is a long time! TM
2014-07-20 13:53 ` Duncan
2014-07-20 14:00 ` Tomasz Torcz
2014-07-20 14:50 ` Austin S Hemmelgarn [this message]
2014-07-20 17:15 ` ashford
2014-07-20 18:21 ` TM
2014-07-20 18:23 ` TM
2014-07-20 19:15 ` Bob Marley
2014-07-20 19:36 ` Roman Mamedov
2014-07-20 19:59 ` ashford
2014-07-21 2:48 ` Duncan
2014-07-21 16:46 ` ronnie sahlberg
2014-07-21 18:31 ` Chris Murphy
2014-07-22 2:51 ` Duncan
2014-07-22 17:13 ` Chris Murphy
2014-07-24 17:19 ` Chris Murphy
2014-07-20 21:28 ` Bob Marley
2014-07-20 21:54 ` George Mitchell
2014-07-21 1:22 ` Wang Shilong
2014-07-21 14:00 ` TM
2014-07-22 1:10 ` Wang Shilong
2014-07-22 1:17 ` Wang Shilong
2014-07-22 14:43 ` TM
2014-07-22 15:30 ` Stefan Behrens
2014-07-22 20:21 ` TM
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=53CBD721.2080502@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=tomek@pipebreaker.pl \
/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.