[Tfug] A/V drives

[Bexley Hall]

Hi, Harry,

--- On Fri, 12/26/08, Harry McGregor <micros at osef.org> wrote:

> > So, to my mind, that doesn't buy you *squat*! (or, *does* it?)
> > I guess it would depend on your available bandwidth and the
> > depth of cache (either in the OS *or* on the drive)
> >
> > Regardless, it's a kludge.
> 
> Yep, take a look here:
> http://www.storagereview.com/guide2000/ref/hdd/op/actRecal.html

Good pointer!

> > Agreed.  While adding memory fixes *many* problems, it doesn't
> > solve *all*.  E.g., adding memory won't make something run cooler  :>
>
> Actually it might.  Adding DRAM to an iPod (original kind,
> not flash based) would let you spin down the drive for longer
> periods of time.

Yes.  As well as giving you "anti-skip" protection.

> > Though this extra smarts in the drive opens the door for
> > other types of failures.  E.g., what happens if the data cached
> > *in* the drive fails to get written onto the media (i.e.,
> > asynchronous writes vs. synchronous writes).
>   
> This is an issue with drive cache, but not normally
> controller cache.

Hmmm... unless the controller can do an up-call to the driver,
you're still faced with the problem.  I.e., if the drive
*dies*, then there are magabytes (?) of cached data that
have no place to go (i.e., you can't "give them back" to
the application to decide how to handle them).

This sort of asynchronous behaviour (decoupling the actual
write from the virtual write) is a frequent cause of problems
as "devices" get smarter.

As a pedantic case, consider the application pushing all this
data out to disk.  The write() returns successfully (despite
the fact that the data is still cached in the controller).
The application *terminates* with a SUCCESS result.

Yet, a fraction of a second (?) later, the controller realizes
that it can't send the data anywhere!  I.e., the application
has *not* successfully terminated (if you define success as
"having achieved every aspect of its intended goal).

[N.B. This is the very sort of issue that caused me to raise
this question in the first place.  If A/V drives were just
"hand waving" and hiding/deferring their actual activities,
then the application is out-of-sync with what is *really*
happening in the system]

> >> The IBM storage array I spoke of has 120GB of memory, of
> >> which quite a bit is used as cache.
> >
> > Is this to improve overall performance (read-ahead,
> > write-behind) or to support special QoS needs?  (e.g.,
> > multimedia, etc.)
>   
> Mostly overall performance.  It does intelligent
> prefetching very well.

Is it tuned to the OS/application?  I.e., so it knows
what the filesystem looks like (instead of just treating
data as "blocks on the media")

> > Or, is it just a good *space heater*???!  :>   (I
> > know my office is 4 degrees warmer than the rest of 
> > the house :-/ )
>   
> at 7kW power draw, it's more than just  space heater :)

<grin>  Yeah, I worked on a system for IBM where the
"CPU chip" drew 500W (100A at -5.2V).  Amazing when you
see what can be done at "extreme scale"!  :>  (you had
to remove all jewelry, eyeglasses, belt buckles, etc.
for fear of *losing* a body part -- 100A through a
gold wedding band will easily take your finger off
but the power supply won't even *blink* at the extra
"load"  :>  )

Unfortunately, it's not a very efficient way to heat a
room...