linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: TM <tmjuju@yahoo.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: 1 week to rebuid 4x 3TB raid10 is a long time!
Date: Sun, 20 Jul 2014 18:23:29 +0000 (UTC)	[thread overview]
Message-ID: <loom.20140720T202250-546@post.gmane.org> (raw)
In-Reply-To: 9781519da9ccf1c860a49d3b7954d00d.squirrel@webmail.wanet.net

 <ashford <at> whisperpc.com> writes:

> 
> Finally, TM didn't mention anything about other I/O activity on the array,
> which, regardless of the method of reconstruction, could have a
> significant impact on the speed of a reconstruction.
> 
> There are a LOT of parameters here that could impact throughput.  Some are
> designed in (the checksum computations), some are "temporary" (the single
> I/O path) and some are end-user issues (slow CPU and other activity on the
> array).  I'm sure that there are other parameters, possibly including soft
> read errors on the other disks, that could be impacting the overall
> throughput.
> 
> As all the information that could affect performance hasn’t been provided
> yet, it is premature to make a blanket statement that the performance of a
> reconstruction is "unreasonable".  For the circumstances, it's possible
> that the performance is just fine.  We have not yet been provided with
> enough data to verify this, one way or another.
> 
> Peter Ashford



Hi Peter,

  I am monitoring closely, I do not have any 'soft-errors' or anything else.
No other users are using the raid10 array. No other compute/disk intensive
tasks etc. So I am providing data -  usual and typical data at least.

  To answer another question, yes I do have backups.

  So this I guess it the speed most users get, which is in my opinion very
slow. 
  And I guess that's around the speed most users will get in similar 4x 3TB
build with low power CPUs.

  Long recovery time, leads to higher risk of another disk failure or other
unexpected failures. 


TM



  parent reply	other threads:[~2014-07-20 18:25 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 [this message]
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=loom.20140720T202250-546@post.gmane.org \
    --to=tmjuju@yahoo.com \
    --cc=linux-btrfs@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).