linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stefan /*St0fF*/ Hübner" <stefan.huebner@stud.tu-ilmenau.de>
To: Drew <drew.kay@gmail.com>
Cc: Simon Matthews <simon.d.matthews@gmail.com>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Recommended sw raid setup
Date: Tue, 05 Jul 2011 08:14:55 +0200	[thread overview]
Message-ID: <4E12ABDF.50409@stud.tu-ilmenau.de> (raw)
In-Reply-To: <CACJz6QuzTj3cmESu0eBGgq3rK3wopXZpj9m34N5ecR=uj6FvCQ@mail.gmail.com>

Am 02.07.2011 23:30, schrieb Drew:
>> I thought that I had read the TLER was not useful for mdraid, so that
>> enterprise drives were not really advised for mdraid. Am I wrong about
>> this?
> 
> TLER just shortens the firmware's error recovery from something like
> 60 seconds down to 4 seconds. It's mainly useful in hardware RAID but
> I can see it being useful with mdraid in the enterprise where you
> can't afford to wait for the drive to do it's own recovery attempts.
> 
> 
This is not correct.  You may want to read the ATA8-ACS2 draft standard
(see www.t13.org).  There you'll find: SCT-ERC

The internal error recovery procedure includes a vast amount of
algorithms.  If a disk cannot read a sector and starts error recovery,
it may take far more than a minute.
With ERC you can tell the disk beforehand to stop processing the command
(may it be "read" or "write") and return a "uncorrectable error" to the
host.  Some drives (i.E. recent Hitachi Deskstar, which I do recommend!)
do not allow you to set ERC lower than 6.5s.

For a home-box I recommend adding a startup-script and a hotplug-script
(as ERC-settings get reset to firmware defaults upon power-on) which
uses smartmontools >=5.41 to set the read-ERC to 7s and the write ERC to
12s.  We have good experience that this works out well in productive
systems.

/Stefan
P.S.: pseudo-knowledge makes important things go really badly wrong.

  reply	other threads:[~2011-07-05  6:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BANLkTinbBu6zX-6s2NYH5BQvnaJZJYt_BA@mail.gmail.com>
2011-07-02 11:16 ` Recommended sw raid setup John Obaterspok
2011-07-02 19:45   ` Drew
2011-07-02 19:48     ` Scott E. Armitage
2011-07-02 21:17     ` Simon Matthews
2011-07-02 21:25       ` Scott E. Armitage
2011-07-02 21:30       ` Drew
2011-07-05  6:14         ` Stefan /*St0fF*/ Hübner [this message]
2011-07-05  6:40           ` Drew
2011-07-03 17:28       ` David Brown
2011-07-03 19:14         ` John Obaterspok
2011-07-03 20:05           ` David Brown
2011-07-03  7:46   ` Emmanuel Noobadmin

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=4E12ABDF.50409@stud.tu-ilmenau.de \
    --to=stefan.huebner@stud.tu-ilmenau.de \
    --cc=drew.kay@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=simon.d.matthews@gmail.com \
    /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).