Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: write-refresh md array (feature request)
Date: Wed, 11 Sep 2013 09:32:23 -0300	[thread overview]
Message-ID: <20130911123222.GA1736@khazad-dum.debian.net> (raw)
In-Reply-To: <CAA9_cmc+hJ9MrGyZDRXbUPNPcpgwm1RNvWQ4yX65zqKZy4puuQ@mail.gmail.com>

On Tue, 10 Sep 2013, Dan Williams wrote:
> On Tue, Sep 10, 2013 at 11:19 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > (please CC me on replies).
> > I've been in several situations where it would have been helpful to be able
> > to refresh weak sectors by rewriting the whole md raid component device,
> > without the need to increase array failure risk through a fail+remove+add
> > cycle for the component device.
> >
> > How difficult would it be to implement a "refresh" as a Linux md driver
> > sync_action, pigging back on "check" ?
> >
> > Are there any drawbacks to write-refreshing component devices?
> >
> 
> Why is "check" insufficient?  If it trips over any bad sectors it will
> re-write them.

The idea is to rewrite the sector _before_ it goes bad.

Consumer SATA HDDs nowadays not only apparently fail to properly remap
sectors because they don't track anymore that some sectors in that subtrack
were reported uncorrect a number of times (and thus are "weak").  They also
appear to not write-refresh sectors that required ECC correction, except
maybe during an offline SMART test routine.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2013-09-11 12:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10 18:19 write-refresh md array (feature request) Henrique de Moraes Holschuh
2013-09-11  1:25 ` Dan Williams
2013-09-11 12:32   ` Henrique de Moraes Holschuh [this message]
2013-09-11 23:05     ` NeilBrown
2013-09-11  6:41 ` CoolCold
     [not found] ` <CAGqmV7ph6JF1cVQwBt-FrzToThMC+gbfPMj3V5EFqbtoOFuFHQ@mail.gmail.com>
2013-09-11 12:37   ` Henrique de Moraes Holschuh
2013-09-11 20:00     ` Dan Williams
2013-09-11 20:15       ` Henrique de Moraes Holschuh

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=20130911123222.GA1736@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=dan.j.williams@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox