Re: Scheduled Transfer Protocol on Linux

[Zachary Amsden]

> While it is entirely possible that you are correct, I think in this case 
> you are mistaken.  I've been in contact with <insert unnamed disk company>
> and they are working on this sort of technology as we speak.  My personal 
> belief is that _ALL_ of the drive companies are looking hard at things which
> add value to the disk drives, because the margins are very low and they are
> looking for something that could drive 'em back up.  A disk drive which is
> also a Linux machine is pretty interesting.  It has people like Cobalt
> squarely in the cross hairs.  Instead of a $1500 box which takes up 2U,
> you can have 8 $300 boxes in the same space, with 8x the performance.

While it certainly is interesting, I can't see any other reason for running 
Linux on a disk drive.  Linux is far too heavy for an embedded marketplace, 
and it really doesn't make sense to run it there.  There are already enough 
splits in Linux targets as it is.  How you can have an operating system that 
runs well on single cpu workstations, scales up to 16-64 cpus, and also runs 
on microcontrollers and realtime systems is beyond me.  Perhaps if it was a 
microkernel it might be feasible.

What is the point of adding a general-purpose OS/CPU/memory system to a disk 
when everything can be done with a couple ASICs much faster and cheaper?  The 
memory footprint that Linux takes could instead be used for valuable disk 
cache.

Maybe if you are talking about huge disk cages, and the cost was amortized 
over a bunch of disks it would be feasible, but if you are talking about 
single drives, this is sheer madness.

-- 
Zachary Amsden  [e-mail]  [phone]  09U-510  Core Protocols