linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).