linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Drew <drew.kay@gmail.com>
To: stefan.huebner@stud.tu-ilmenau.de
Cc: Simon Matthews <simon.d.matthews@gmail.com>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Recommended sw raid setup
Date: Mon, 4 Jul 2011 23:40:35 -0700	[thread overview]
Message-ID: <CACJz6Qt2n0hcP6pmL3n0ZQs5aEDb_=L-4P-O4MZoUFeF+tUU_w@mail.gmail.com> (raw)
In-Reply-To: <4E12ABDF.50409@stud.tu-ilmenau.de>

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

And how is that any different from what I said? The observable effect
of TLER is the drive giving up after a few seconds instead of a minute
or more. Algorithm XYZ and spec ABC of the t13 committee doesn't
change what we see. And for most people, the effect is what matters,
not how we got there.

Myself, I could care less about what goes on under the hood. I enable
TLER for HW raid and disable it for regular use.


-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie

"This started out as a hobby and spun horribly out of control."
-Unknown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-07-05  6:40 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
2011-07-05  6:40           ` Drew [this message]
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='CACJz6Qt2n0hcP6pmL3n0ZQs5aEDb_=L-4P-O4MZoUFeF+tUU_w@mail.gmail.com' \
    --to=drew.kay@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=simon.d.matthews@gmail.com \
    --cc=stefan.huebner@stud.tu-ilmenau.de \
    /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).