From: Bill Davidsen <davidsen@tmr.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Redeeman <redeeman@metanurb.dk>, David Lethe <david@santools.com>,
Jon Nelson <jnelson-linux-raid@jamponi.net>,
Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-raid@vger.kernel.org
Subject: Re: upgrade advice
Date: Mon, 12 Jan 2009 22:00:16 -0500 [thread overview]
Message-ID: <496C03C0.8050407@tmr.com> (raw)
In-Reply-To: <yq17i5yhkvl.fsf@sermon.lab.mkp.net>
Martin K. Petersen wrote:
> People always seem to assume that hardware is what's making the
> difference between consumer and enterprise. It's not. The physical
> hardware differs mostly due to capacity vs. RPM trade-offs. Most
> vendors these days have big platters for high-capacity drives and
> smaller platters for high RPM/higher IOPS class drives. On top of
> that, head/platter count may vary in capacity classes within a series.
>
> But the important difference between consumer and enterprise drives is
> not mechanical. It's the firmware. Consumer drive firmware is about
> squeezing out the most capacity/$ and nothing else.
>
>
That's simply not the case. Cost is one of the issues, but the typical
use of the drive is one of the most important things about the firmware.
With consumer drives, it's likely that this is the one and only drive
holding the data, so clever retries in case of error are important. With
server grade drives, it's likely they are in a RAID, so returning the
error quickly so the controller or OS can compensate is the important
issue. That's been discussed here before, some drives even give you a
choice of "don't hang up" vs. "try like hell" on errors, through jumpers
or firmware.
> Enterprise drives trade capacity for reliability by way of the
> firmware. That includes many things like using more space for track
> info (gap/sync), much better ECC, better tolerance for rotational
> vibration, etc.
>
> Most of the errors you see on drives are a result of media errors that
> are big enough that the drive ECC can't correct them. Errors are
> often caused by head misses due to bad tracking, vibration from other
> drives in the enclosure, the user kicking the cabinet at an
> inopportune moment, etc. I.e. external interference. Other errors
> are due to real imperfections of the media itself.
>
>
I would be surprised if a consumer grade drive doing more retries over
several seconds rather than several rotations wasn't better able to
correct for most of the transient problems you mention. So your comments
about transient mechanical issues aren't telling me much, other than
server drives being more likely to get vibration from other drives.
> Enterprise drive firmware is about being more resistant to outside
> factors as well as real media defects. That firmware cost more to
> develop than the consumer ditto. And the vendors charge a premium for
> it.
>
>
Other than possibly having more ECC bits there isn't much difference, as
several people here have noted you don't want the drive to hang for
several seconds trying this and that in a server environment. And given
that there are a very small number of things to be done on error, like
reread, seek away and back, recalibrate, etc, I would be amazed if
vendors didn't just put all the code in the firmware and use a little
table to determine which actions to take in what order, and how many
times. The idea of some vast and complex code just doesn't fly, there
aren't that many things to try.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2009-01-13 3:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 11:10 upgrade advice Max Waterman
2008-12-16 11:44 ` Justin Piszcz
2008-12-16 11:49 ` Redeeman
2008-12-16 13:07 ` Justin Piszcz
2008-12-16 14:15 ` Redeeman
2008-12-16 15:57 ` Jon Nelson
2008-12-16 16:10 ` Ryan Wagoner
2008-12-16 16:27 ` Redeeman
2008-12-16 23:29 ` Justin Piszcz
2008-12-17 0:08 ` Jon Nelson
2008-12-17 6:59 ` Redeeman
2008-12-17 13:26 ` Jon Nelson
2008-12-17 14:28 ` David Lethe
2008-12-17 14:37 ` Jon Nelson
2008-12-17 15:30 ` David Lethe
2008-12-18 7:36 ` Redeeman
2008-12-18 16:37 ` John Robinson
2008-12-18 16:43 ` Justin Piszcz
2008-12-18 17:18 ` John Robinson
2008-12-18 19:14 ` upgrade advice / Disk drive failure rates - real world David Lethe
2008-12-18 22:51 ` Max Waterman
2008-12-19 4:28 ` David Lethe
2008-12-17 14:46 ` upgrade advice Redeeman
2008-12-17 15:38 ` Martin K. Petersen
2009-01-13 3:00 ` Bill Davidsen [this message]
2009-01-13 4:37 ` Martin K. Petersen
2008-12-16 13:09 ` Max Waterman
2008-12-16 13:04 ` Max Waterman
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=496C03C0.8050407@tmr.com \
--to=davidsen@tmr.com \
--cc=david@santools.com \
--cc=jnelson-linux-raid@jamponi.net \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=redeeman@metanurb.dk \
/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).