From: Hans Kraus <hans@hanswkraus.com>
To: linux-raid@vger.kernel.org
Subject: Re: Timeout question
Date: Wed, 06 Nov 2013 07:49:03 +0100 [thread overview]
Message-ID: <5279E65F.8020209@hanswkraus.com> (raw)
In-Reply-To: <5278220C.3060607@turmel.org>
Hi Phil,
thanks. Debian does already a scrub every first Sunday of a month.
Upgrading to a Raid6 is planned when I have the money for the disk(s).
I already encountered a second failure during rebuild of a raid5, (that
was the trigger for the backup solution), so I'm very aware of that
possibility. My main storage is already a raid6, on NAS drives.
Kind regards, Hans
Am 04.11.2013 23:39, schrieb Phil Turmel:
> [...]
>> Afterwards, these four raid0 are the members of a raid5. The idea
>> behind this is to be able to replace the raid0 with single 4 TB drives.
>> Now comes my question: Do I need to care for timeouts of the raid0, and
>> if so, how do I do that? The following doesn't work:
>> for x in md??; do
>> /bin/echo $x
>>
"--------------------------------------------------------------------------"
>>
>> echo 180 >/sys/block/$x/device/timeout || echo
>> "/sys/block/$x/device/timeout not available"
>> /bin/echo
>>
"-------------------------------------------------------------------------------"
>>
>> done
>
> No. The timeouts only matter on the physical devices. MD doesn't have
> a timeout as it isn't a physical driver. What you have appears to be
> correct.
>
> Make sure you also have a "check" scrub in a cron job for everything
> greater than raid0. (Interval can vary--I use weekly.) And follow up
> on the cron job with a report of all mismatch-cnt values.
>
> For large capacities with consumer drives (~8TB or more, IMHO), you
> should seriously consider raid6. The probability of an unrecoverable
> read error interrupting a raid5 rebuild after a drive failure is
> shockingly high.
>
> HTH,
>
> Phil
prev parent reply other threads:[~2013-11-06 6:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 20:07 Timeout question Hans Kraus
2013-11-04 22:39 ` Phil Turmel
2013-11-04 23:29 ` Keith Keller
2013-11-06 6:49 ` Hans Kraus [this message]
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=5279E65F.8020209@hanswkraus.com \
--to=hans@hanswkraus.com \
--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.