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 --]
next prev parent 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