From: Stan Hoeppner <stan@hardwarefreak.com>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: linux-raid@vger.kernel.org
Subject: Re: thanks md raid
Date: Thu, 10 May 2012 21:09:44 -0500 [thread overview]
Message-ID: <4FAC74E8.7040108@hardwarefreak.com> (raw)
In-Reply-To: <4FAC387E.1010006@pocock.com.au>
On 5/10/2012 4:51 PM, Daniel Pocock wrote:
>
>
> On 10/05/12 21:49, Stan Hoeppner wrote:
>> On 5/10/2012 1:54 PM, Daniel Pocock wrote:
>>>
>>> I'm glad my RAID1 worked as expected... just hoping I don't encounter
>>> any read timeouts on the non-TLER drive before my rebuild finishes:
>>
>> You have an inverse understanding of ERC. Drives without ERC will retry
>> forever, or until an upper layer puts a stop to its efforts. Drives
>> with a 7 second ERC will return a hard error after 7 seconds.
>>
>> So the only way you'll get a timeout with your rebuild is if the healthy
>> drive spends 30 seconds retying a sector read.
>>
>
> I was thinking about the more obscure case - that some other URE
> followed by an attempt at write access on the good drive fails and it
> becomes degraded
If drives were that damn fragile modern computing wouldn't exist. The
odds of your UPS taking a dump during a rebuild are greater than the
scenario you just described. You need to put more thought into UPS
failure scenarios than ERC.
I mention this specifically because my "desktop" APC Backups XS 900 did
the unthinkable the other day. Apparently it decided the batteries were
bad at the very moment it ran its hard scheduled self test. Class, what
happens with all APC UPSes when the scheduled self test runs and the
batteries have been flagged bad? Answer: it drops the load and causes
your system to reboot.
One would think APC would be smart enough to have the firmware skip the
self test until after the batteries have been replaced, specifically to
prevent an unplanned power event, the whole purpose of a UPS. I guess
one of their actuaries figured they'd get more battery sales if they
keep downing your system until you replace them...
--
Stan
prev parent reply other threads:[~2012-05-11 2:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 18:54 thanks md raid Daniel Pocock
2012-05-10 21:49 ` Stan Hoeppner
2012-05-10 21:51 ` Daniel Pocock
2012-05-11 2:09 ` Stan Hoeppner [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=4FAC74E8.7040108@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=daniel@pocock.com.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 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).