linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 



  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).