Re: SCSI and EIDE

[Kevin M Bealer <kmb203@psu.edu>]

On Tue, 13 Aug 1996, Sherwood Botsford wrote:

> > This is known as elevator seeking and should be done at the OS level.
> > The order that data is written out is very important for data
> > reliability, and for this reason, I don't think any hard disk change
> > the order of the writes.  
> 
> There are several different algolrithms for doing this.  Elevator seek
> is the simplest of them.  Some put a higher priority on reads over
> writes.  Some re-priortize the queue so that requests that have been
> outstanding for a while get bumped up the queue.  

Linux currently uses (accord. to the kernel lists) something
called sawtooth ordering.  This means the head moves in the same
direction until no more is left to read in that direction, then
does the same in the other direction... This provides more
"fairness" ie applications with data at the extreme ends of the
disk don't stall for a long time.

> I agree that you can do this in the OS, but I don't think that it
> *should* be done in the OS.
> 0.	In general smarts should be at the point they are used. We had a
> VAX that was about as speedy as a 12 MHz 286 with 287 co-processor.
> However, that vax could handle 8 simultaneous 19 KB terminal lines.
> How?  Smart serial cards.  

I agree for most hardware, but some issues of hard drive usage,
ie reading ahead, really should have support, not only in the
kernel but in the application, for best performance.  The
application knows more about it's usage patterns, which could
help in speeding up hardware.  (for example, "file" only reads a
small chunk of a file, but grep always scans the entire file.)

> 	The CPU should do those tasks that are either too general for
> dedicated hardware, or that don't happen often enough to take up much
> time.
> 1.	The OS shouldn't have to care about the layout of the disk.
> 2.	I don't understand why the order matters for reliability --
> unless you're talking about power failures.  This is a low order failure
> mode -- which is why you do backups -- for those rare occasions when the
> disk does lose a file when the lights go out.  The disk is smart enough
> to recognize that a new request to write out sector 12345 makes the
> previous request to write out sector 12345 invalid.

The reasoning is that the filesystem should be in an
"inconsistent" state as little as possible. (ideally...)  This
is for power failures, kernel oops'es, etc.

> 3.	The kernel of any unixen caches metadata for most of the file
> system for long periods of time.  This is the whole point of the sync
> daemon -- to flush this out to disk. 
> 
> 
> Sherwood Botsford |Unsolicited email that advertises commercial 
> Physics Dept      |activities will consitute a request for 
> U of Alberta      |spellchecking of all words of less than three 
> Edmonton, AB,     |characters.  I charge $US500 for this service. 
> T6G 2J1		  |There is no warranty of correctness of this service. 

I think the OS's job should be efficiency, reliability, etc. 
Hardware is nice... but doing it in software is cheaper.  If
Linux can do well on cheap flaky hardware, more power to it.

__kmb203@psu.edu_______________Debian/GNU__1.1___Linux__2.0.11___
    THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP
This otherwise unremarkable language is distinguished by the
absence of an "S" in its character set; users must substitute
"TH".  LITHP is said to be useful in protheththing lithtth.