chris@mimsy.umd.edu (Chris Torek) (02/14/90)
In article <19451@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >While I'm on the subject, a thought on disk/partition/file system >organization: > >The current situation is really a mess, with all the partitioning >and defect mapping burried down in *each* disk driver. What we >need is truly raw drivers for specific hardware and a generic >indirect driver implementing "cooked" features -- mapping, >partitioning, striping, mirroring -- in a *standard* way. 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 label code, however, is larger, and I am trying to do something like the above in a new device organisation I am working on (still in design phase mostly). Right now I am not interested in striping or mirroring, and do not want to do anything that would affect the buffer cache code---striping has a tendency to do this---since this code is changing: already the 4.4ish code at Berkeley differs from what I am using here. The idea, however, is much the same: every hardware disk driver must provide a common interface, and a software layer uses this to add standard features to all disks. (My scheme goes a bit further than this, but this is what sparked it.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
steve@nuchat.UUCP (Steve Nuchia) (02/16/90)
In article <22520@mimsy.umd.edu> chris@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