Promptness, queueing, diskless etc. etc.

[Jonathan Shapiro]

   >In my opinion, the case for large pages has nothing to do with disk
   >speed.  Even at 4K, the page size is substantially larger than a disk
   >sector.

   The issue involves the overhead of starting operations and fielding
   interrupts.  How do you get enough data to the CPU so it isn't spending
   all its time doing I/O grunt work.  I believe the IBM work in this
   area assumed a channel.

There are two countervailing trends: the larger the disk transfer unit
is, the less relevant the content may be, and the more unused data
will be transferred.

Perhaps more important, given your concern about interrupts, is that
growing the disk transfer size may lead to *more* interrupts rather
than less, because a greater percentage of disk pages will span
multiple tracks.  Such multitrack pages need to be read in multiple
operations, requiring multiple interrupts.

   You can always do what UNIX/NFS does ;-).  Particulary if you are running
   programs designed for non-persistant systems, you can zap them if they
   depend on something that was damaged in the crash.

The problem lies in the definition of "depend."  If a domain holds a
start key to a dead domain, is that domain considered dead?  How does
one indicate "precious" domains that should *not* be considered dead
under these conditions?


Jonathan