[nylug-talk] Paper IT certs and disk drive fabrication differences -- WAS: Slim home server

[Chris Knadle]

On Wednesday 21 May 2008, Bryan J. Smith wrote:
> On Sat, 2008-05-17 at 18:49 -0400, Chris Knadle wrote:
Re: Near-line or "enterprise" drives vs "commodity" drives
> > Oddly enough -- no.  Most of the servers I personally helped purchase
> > were from vendors that allowed specifying hardware choices.  If standard
> > servers from HP or others were purchased it just so happened that the
> > hardware wasn't used on projects I worked on.
>
> Okay.  So you really haven't.

   At least not knowingly, yeah.

> Understand the whole certification and sample QA on commodity disks --
> near-line/enterprise/RAID/etc... OEM versus consumer/desktop OEM/retail
> is for cost reasons.
...
> Hitachi, Seagate and Western Digital are not going to warranty disks
> that Dell, HP, IBM, etc... sell in systems that are running 24x7 and are
> not of these samples.  Again, anyone who has been a product manager will
> instantly see the cost differentiation en masse.  They are also far less
> likely to warranty or even charge you a fee if you are sending _many_
> consumer rated discs back to them and the SMART data is coming back as
> operating 24x7, or has other operational data that is well outside
> general, consumer usage.  Not one or two-off, but when you end up
> sending dozens.

   I'm having trouble with the above paragraph; I just don't buy the idea that 
hard disk manufacturers can drop warranty support based on the number of 
hours per day that they are used.

   Let's cut to the chase and examine a specific example.  Examine the link 
below, and choose the "Ultra ATA/100  500GB  ST3500630A" selection (didn't 
post a direct link because it was just too long, and the ST3500630A happens 
to be a disk model that I'm using).

http://www.seagate.com/www/en-us/products/desktops/barracuda_hard_drives/barracuda_7200.10/

   Nowhere in the documentation listed are there any specified limitations on 
the number of hours per day that the disk should be used.  Not the 
specifications, not the datasheet, not the warranty.  And it's a 5-year 
warranty on a commodity disk.
   The fact that it's meant to be a "desktop hard disk" doesn't mean anything, 
at least not to me, because some people never turn their desktop computers 
off, and I think that's to be expected.

   I think I understand that your point is that "enterprise" drives are meant 
for continuous use and that "commodity" drives are not, but I personally 
can't bring myself to agree with that conclusion.  My gut says no, 
my "engineering intuition" says no, and from what I can see the online 
documentation doesn't support that conclusion either.
   If they're only supposed to be used 8 to 14 hours per day, that has to be 
in the documentation, or else I believe any court is unlikely to rule in the 
manufacturer's favor should a legal case be brought.

   The only thing I can see a manufacturer doing is looking at the purchase 
date of the drive, and whether the drive had an event happen to it that isn't 
covered by the warranty; drop > X number of G's, opening the case, lost 
password, etc...  there's a list of those stated exceptions in the warranty.

...
> I have more recently been in the middle of an Intel debacle, and their
> utterly lack of full disclosure (even to us vendors under NDA) with
> regardless to Machine Check Exception (MCE) issues -- specifically, as
> you can find in public documentation now -- the TLB.  Yes, TLB.  AMD
> isn't alone.  ;)

   I assume you mean the list of hardware errata not matching reality.  That 
comes up on LKML relatively often.  :-/

> Made me completely appreciate AMD's decision to withhold their Processor
> 10h (Barcelona) Stepping B2 multi-socket (Opteron) processors until they
> worked out all the TLB issues on the B3.  Intel shipped G0 steppings on
> not just their uni-socket Core 2s, but their multi-socket Xeons.  I was
> hitting the Intel microcode dat file for Linux weekly for some time
> there.  ;)

   Wow, you mean you've actually replaced the CPU microcode?  I know it's 
possible, I've seen the drivers in the kernel for it, and there's now a 
Debian package in Unstable for the Intel microcode...  I just haven't known 
anybody to actually DO it yet.  :-)
   The circumstances might have been unfavorable but I'm glad to know of it 
being done successfully.

> Can't say more than is public, being under NDA and all.

   Understood.

> But SAS, just like SCSI or FC, has nothing to do with the reliability of
> the drive mechanics itself.  It's more of the non-commodity pairing of
> cost in fab with cost in firmware.

   Right, that makes sense to me.

   -- Chris

-- 

Chris Knadle
Chris.Knadle at coredump.us