disk drivers (was What new system calls do you want in BSD?)

[Steve Nuchia]

In article <22520 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>The partition code is not very big, and the defect mapping code is
>extremely device dependent (so much so that only a few BSD drivers can
>share it; they do this via subroutines in `dkbad.c').  The disk

Thanks for the update.  My motivation for wanting the defect mapping
centralized is the vast frustration that results from dealing with
the brain-dead, undocumented, silly schemes the "value added" bozos
keep foisting upon the system integrator.  I know that things like
sector slipping happen at a low level, but once it is said and done
it would be nice to have the residual mapping and mapping for devices
that don't have a low level mechanism (like floppies, occasionally)
happen at a high level.

I see two benefits to doing it this way -- one, it makes it possible
to write a portable, device independent, safe program to spare failing
sectors, and it makes it possible for the elevator to know about long seeks
induced by the sparing mechanism, something that it (often) doesn't
do now.  I have vivid memories of a 14" disk with a plastic top that
would go into spastics when I read a file on a cylinder with a bad track.
(old sysIII, track sparing to the end of the disk).

Also, I can understand you not being interested in mirroring and
striping, but from an architectural perspective wouldn't it make
sense to define a layer like the one I'm describing as the "right"
place to put such features?  And devise a mechanism for writing
such features in the field?
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"If the conjecture `You would rather I had not disturbed you
 by sending you this.' is correct, you may add it to the list of
 uncomfortable truths."   - Edsgar Dijkstra