From: ashford@whisperpc.com
To: "Roman Mamedov" <rm@romanrm.net>
Cc: "Bob Marley" <bobmarley@shiftmail.org>, "TM" <tmjuju@yahoo.com>,
linux-btrfs@vger.kernel.org
Subject: Re: 1 week to rebuid 4x 3TB raid10 is a long time!
Date: Sun, 20 Jul 2014 12:59:21 -0700 [thread overview]
Message-ID: <37e3a8cf8b7439d5cd2745b5efb9d37f.squirrel@webmail.wanet.net> (raw)
In-Reply-To: <20140721013609.6d99c399@natsu>
This is the cause for the slow reconstruct.
> I believe the problem here might be that a Btrfs rebuild *is* a strenuous
> random read (+ random-ish write) just by itself.
If you assume a 12ms average seek time (normal for 7200RPM SATA drives),
an 8.3ms rotational latency (half a rotation), an average 64kb write and a
100MB/S streaming write speed, each write comes in at ~21ms, which gives
us ~47 IOPS. With the 64KB write size, this comes out to ~3MB/S, DISK
LIMITED.
The on-disk cache helps a bit during the startup, but once the cache is
full, it's back to writes at disk speed, with some small gains if the
on-disk controller can schedule the writes efficiently.
Based on the single-threaded I/O that BTRFS uses during a reconstruct, I
expect that the average write size is somewhere around 200KB.
Multi-threading the reconstruct disk I/O (possibly adding look-ahead),
would double the reconstruct speed for this array, but that's not a
trivial task.
The 5MB/S that TM is seeing is fine, considering the small files he says
he has.
Peter Ashford
next prev parent reply other threads:[~2014-07-20 19:59 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
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 [this message]
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=37e3a8cf8b7439d5cd2745b5efb9d37f.squirrel@webmail.wanet.net \
--to=ashford@whisperpc.com \
--cc=bobmarley@shiftmail.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
--cc=tmjuju@yahoo.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).