Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.ru>
To: Chris Murphy <lists@colorremedies.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: 3TB drives failure rate
Date: Mon, 29 Oct 2012 03:18:51 +0600	[thread overview]
Message-ID: <20121029031851.42a5e1e9@natsu> (raw)
In-Reply-To: <6FAB7F92-66E2-4276-9774-B80DAC92E450@colorremedies.com>

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Sun, 28 Oct 2012 15:07:53 -0600
Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Oct 28, 2012, at 2:50 PM, Chris Murphy <lists@colorremedies.com> wrote:
> 
> > For any serious use I just wouldn't use the Greens, without very non-consumer like scrubs, extended smart tests, and cycling out drives so they could be ATA Enhance Secure Erase nuked say once a year or maybe more often. And a rigorous backup. With that kind of expertise and dedication should come a better budget for a better drive.
> 
> On 2nd thought, I'd consider the greens something like a "hostile witness" in legal jargon. Relegate them to only ZFS or btrfs (or ReFS maybe, unclear) for "raid" like pooling or redundancy. The drives themselves are inherently suspect so a suspicious grand inquisitor of a file system seems like an appropriate match, to constantly 2nd guess them.

Now you are moving into unfounded superstitions territory.

You seem to imply that a Green drive would return just plain bad data in some
failure condition (else why all the checksumming FSes?), and not an IO Error.
I don't think anything of this sort has been demonstrated so far, and while
this could happen due to bad RAM/chipset/controller/bus/cache/etc, this would
have nothing to do specifically with "Greenness" of a drive, nor any
particular model would be inherently more prone to that.

> But still, once a drive is asked to retrieve an LBA, so long as the drive eventually reports it back correctly, the file system won't correct that sector merely for a delay, even if it is up to 2 minutes or whatever it is. So, filesystem choice doesn't really solve the delay problem. You just have to obliterate the disk periodically with zeros or secure erase.

I do not think there is a state in modern HDDs that there would be a sector
which consistently takes 30-120 seconds to read. Those are either unreadable at
all, or readable after a delay -- and then already remapped by the HDD into the
reserved zone, so the delay is not there the next time.

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-10-28 21:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-28 12:15 3TB drives failure rate Rainer Fügenstein
2012-10-28 12:19 ` Mathias Burén
2012-10-28 12:49   ` John Robinson
2012-10-28 12:54 ` Michael Tokarev
2012-10-28 16:47 ` Ed W
2012-10-28 17:05   ` Joe Landman
2012-10-28 22:12     ` joystick
2012-10-28 22:24       ` Miles Fidelman
2012-10-28 23:59         ` joystick
2012-10-29  0:09           ` Miles Fidelman
2012-10-29  4:29             ` Roman Mamedov
2012-10-29  7:54               ` David Brown
2012-10-29 13:02                 ` Phil Turmel
2012-10-30 23:54                   ` 3TB drives failure rate (summary) Rainer Fügenstein
2012-10-31 12:35                     ` Phil Turmel
2012-11-01 15:13                       ` Miles Fidelman
2012-11-01 15:24                         ` John Robinson
2012-11-01 15:39                           ` Miles Fidelman
2012-11-01 16:05                             ` John Robinson
2012-11-01 16:25                               ` Miles Fidelman
2013-02-05 17:43                       ` Adam Goryachev
2013-02-05 18:08                         ` Roy Sigurd Karlsbakk
2013-02-05 20:34                         ` Wolfgang Denk
2012-10-29 13:26               ` 3TB drives failure rate Miles Fidelman
2012-10-28 19:50 ` Chris Murphy
2012-10-28 19:59   ` Roman Mamedov
2012-10-28 20:10     ` Chris Murphy
2012-10-28 20:16       ` Roman Mamedov
2012-10-28 20:34         ` Chris Murphy
2012-10-28 20:49           ` Roman Mamedov
2012-10-28 20:59             ` Chris Murphy
2012-10-28 21:07               ` Miles Fidelman
2012-10-28 20:50           ` Chris Murphy
2012-10-28 21:07             ` Chris Murphy
2012-10-28 21:18               ` Roman Mamedov [this message]
2012-10-28 21:24                 ` Mikael Abrahamsson
2012-10-28 21:45                 ` Miles Fidelman
2012-10-28 22:35                   ` Chris Murphy
2012-10-28 21:51                 ` Chris Murphy
2012-10-28 21:59           ` joystick
2012-10-28 22:10             ` Phil Turmel
2012-10-29  0:12               ` joystick
2012-10-29  0:21                 ` Phil Turmel
2012-10-29  0:27                 ` Chris Murphy
2012-10-28 21:21 ` Mikael Abrahamsson
2012-10-28 23:51 ` Peter Kieser

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=20121029031851.42a5e1e9@natsu \
    --to=rm@romanrm.ru \
    --cc=linux-raid@vger.kernel.org \
    --cc=lists@colorremedies.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