Settling the HD debate WAS: Re: [mythtv-users] A warning about Samsung HDDs

[Steve Adeff]

On Tuesday 01 November 2005 13:54, Robert Denier wrote:
> On Tue, 2005-11-01 at 10:57 -0500, Steve Adeff wrote:
> > On Monday 31 October 2005 15:20, Robert Denier wrote:
> > > I didn't see this mentioned so I thought I'd add it.  Hard drives come
> > > with different amounts of cache ram.  I believe 16MB is about the
> > > largest out now.
> > >
> > > The point being that a larger cache may result in a bit less work for
> > > the moving components which in turn may result in longer life.  I'm not
> > > sure this would matter in practice though.  Still, if your getting a
> > > new drive, I'd look for at least an 8MB cache for performance reasons
> > > if nothing else..
> >
> > in fact all the extra cache does is allow the drive to appear to operate
> > faster. hdparm has a -t and -T tests, one for cache speeds one for actual
> > disk speeds. Since the amount of data being written stays the same there
> > is
>
> Cache is potentially useful against wear and tear if it causes the total
> amount of head motion to be less.  Perhaps the program asks for the
> first 50KB right then, but in a subsequent operation 5 seconds later it
> asks for the next 50KB.  Now the head could be anywhere 5 seconds later
> and have to go back to read that next 50kb.  If, on the other hand, it
> read the next 100KB into cache memory during the initial read, it can
> directly refer to that and save on one positioning of the head.
>
> Does it work exactly like this in practice?  I don't know.  I never
> studied caching algorithms to that degree, and from what someone else
> said, the cache size doesn't seem to affect reliability in practice, and
> in the end those are the results that matter.
>
> Still, caching is an important technology.  No, it doesn't always work,
> but you wouldn't see it all over computer architecture if it didn't have
> some significant benefits...
>
> -Robert

except that a drive can be given a command to write cached data immediately. 
Otherwise if the drive were to lose power suddenly, any data in the cache 
would be lost. so the operating system basically sends this command to the 
drive after every "save this data to the disk" command. The cache comes in 
when your say writing a 200meg file to the disk. The cache is used as a 
buffer to negate the time delay of head movement as it seeks to empty areas 
on the platter. So if your drive has 50megs free here, 5 there, 10 somewhere 
else, etc. as it writes the 200meg file and has to seek between these points, 
the cache lets the processer keep sending the drive data without it having to 
slow down for these head movements. Small 100K, 50K files are sent to the 
drive followed by the "save cache data to disk" command. 

You could rewrite how the ide drivers do this, and I think linux actually 
makes it easier by changing compile time variables, and perhaps even 
load-time variables, but its silly to do this unless you really know what you 
are doing and how this all works together (or your playing with it to see how 
it all works).

From what I remember, the heads sit on a silicone-viscous bearing, basically a 
gel bearing (as opposed to, say a ball-bearing bearing). This gel can handle 
the movement of the head back and forth basically indefinitely (assuming 
proper manufacturing with no flaws beyond specifications), and since the 
mechanism moving the head back and forth is operated by electromagnets there 
is no motor/gearing to wear.

Steve