linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roger Heflin <rogerheflin@gmail.com>
To: Phil Turmel <philip@turmel.org>
Cc: Geoff Back <geoff@demonlair.co.uk>, Nix <nix@esperi.org.uk>,
	Wols Lists <antlists@youngman.org.uk>,
	David T-G <davidtg+robot@justpickone.org>,
	Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: hardware recovery and RAID5 services
Date: Mon, 31 Jan 2022 13:46:34 -0600	[thread overview]
Message-ID: <CAAMCDee4yWfockZLKyPqj_UbrBv02=97yfPuchG-Ahd8sRdd4A@mail.gmail.com> (raw)
In-Reply-To: <698869e2-b45c-a355-f58b-d7b1b4f7830d@turmel.org>

I have been warranty/replace them when the sectors refuse to
reallocate, and/or the disks continue to hit the ERC/TLER timeout all
of the time with bad sectors growing rapidly with no end in sight.

If one is using raid6 and given the low rate of bad sectors, then it
is pretty unlikely that there will be data loss.  If one was using
raid5 things would be more worrisome.


On Mon, Jan 31, 2022 at 1:21 PM Phil Turmel <philip@turmel.org> wrote:
>
> On 1/31/22 14:07, Geoff Back wrote:
>
> >
> > If a disk has one or more bad sectors, surely the only logical action is
> > to schedule it for replacement as soon as a new one can be obtained; and
> > if it's still in warranty, send it back.  If the data is valuable enough
> > to warrant use of RAID (along with, presumably, appropriate backups)
> > surely it is too valuable to risk continuing to use a known faulty disk?
> >
> > In which case, I would suggest that dangerous experiments that try to
> > force the disk to reallocate the block are arguably pointless.
> >
> > Just my opinion, but one that has served me well so far.
> >
> > Regards,
> >
> > Geoff.
>
> I would be surprised if you got warranty replacement just for a few
> re-allocated sectors.  The sheer quantity of sectors in modern drives
> and the tiny magnetic domains involved means **no** drive is error-free.
>   Just most defects are identified and mapped out before shipping.
> Reallocations cover the marginal cases.
>
> I replace drives when re-allocations hit double digits, though I've had
> to run a few corners cases well past that point.
>
> Phil

  reply	other threads:[~2022-01-31 19:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-21 16:48 hardware recovery and RAID5 services David T-G
2022-01-21 19:31 ` Wols Lists
2022-01-21 19:34   ` Wols Lists
2022-01-21 19:47     ` Wols Lists
2022-01-22 14:23       ` Roger Heflin
2022-01-22 22:23         ` Phil Turmel
2022-01-23  0:20           ` anthony
2022-01-29 15:25           ` David T-G
2022-01-29 15:36           ` Wols Lists
2022-01-31 15:39             ` Nix
2022-01-31 18:59               ` Roger Heflin
2022-01-31 19:07                 ` Geoff Back
2022-01-31 19:21                   ` Phil Turmel
2022-01-31 19:46                     ` Roger Heflin [this message]
2022-01-31 20:04                     ` Geoff Back
2022-01-31 20:53                     ` Wols Lists
2022-01-29 15:21   ` David T-G

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='CAAMCDee4yWfockZLKyPqj_UbrBv02=97yfPuchG-Ahd8sRdd4A@mail.gmail.com' \
    --to=rogerheflin@gmail.com \
    --cc=antlists@youngman.org.uk \
    --cc=davidtg+robot@justpickone.org \
    --cc=geoff@demonlair.co.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=nix@esperi.org.uk \
    --cc=philip@turmel.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).