All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eyal Lebedinsky <eyal@eyal.emu.id.au>
To: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: RFC - Raid error detection and auto-recovery (was Fault tolerance with badblocks)
Date: Fri, 12 May 2017 09:31:49 +1000	[thread overview]
Message-ID: <4da6b084-e975-0d33-806f-40cf94434559@eyal.emu.id.au> (raw)
In-Reply-To: <20170510170744.GB2925@lazy.lzy>

On 11/05/17 03:07, Piergiorgio Sartor wrote:
> On Wed, May 10, 2017 at 02:26:12PM +0100, Wols Lists wrote:
[trim]
>>
>> Coders and code welcome ... :-)
>
> I just would like to stress the fact that
> there is user-space code (raid6check) which
> perform check, possibily repair, on RAID6.

Short summary: the detect/correct options suggested by the OP are valuable.

raid6check is not the same thing. As an exercise I decided to run raid6check
instead of a raid 'check'. It is *very* slow. It seems to read the disks
sequentially (not in parallel).

After running for a day iostat shows the disks are read at about 6.5MB/s each,
which is a fraction of the raw performance of the disks (above 160MB/s).
These are 4TB disks so I expect the run will last about a week?
It probably started faster and will end slower.

A raid check starts at over 140MB/s and ends at above 70MB/s. It completes
in just under 10 hours.

For reference, the smart long test time suggests around 450 minutes (7.5 hours).

I checked iostat when there was no other activity on this array.
Unfortunately the program does not offer any progress option that I can see.

cheers

> bye,
>
>>
>> Cheers,
>> Wol

-- 
Eyal Lebedinsky (eyal@eyal.emu.id.au)

  reply	other threads:[~2017-05-11 23:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-10 13:26 RFC - Raid error detection and auto-recovery (was Fault tolerance with badblocks) Wols Lists
2017-05-10 17:07 ` Piergiorgio Sartor
2017-05-11 23:31   ` Eyal Lebedinsky [this message]
2017-05-15  3:43 ` NeilBrown
2017-05-15 11:11   ` Nix
2017-05-15 13:44     ` Wols Lists
2017-05-15 22:31       ` Phil Turmel
2017-05-16 10:33         ` Wols Lists
2017-05-16 14:17           ` Phil Turmel
2017-05-16 14:53             ` Wols Lists
2017-05-16 15:31               ` Phil Turmel
2017-05-16 15:51                 ` Nix
2017-05-16 16:11                   ` Anthonys 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=4da6b084-e975-0d33-806f-40cf94434559@eyal.emu.id.au \
    --to=eyal@eyal.emu.id.au \
    --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 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.