Record-access libraries (Was: Re: VMS vs. UNIX file system)

Eric S. Raymond eric at snark.UUCP
Thu Oct 6 01:32:59 AEST 1988


In article <258 at cvbnet2.uucp>, aperez at blazer.uucp (Arturo Perez Ext.) writes:
>                                      But say I had a fixed block
> file that I only accessed randomly, occasionally sequentially but not
> too often.  Wouldn't it be a useful embedded attribute of the file?
> That way the kernel wouldn't waste too much of its time trying to do
> readahead for me, which I won't be using anyway. 

Yes, but useful how often? That is, is the additional kernel and interface
complexity justified by the gain in that one case?

One of the great insights of the UNIX file system design is that, practically
speaking, all forms of file structuring above byte stream level have a low
marginal advantage relative to their complexity cost. I could argue for this
on lots of theoretical grounds, but I don't have to; the overwhelming
*practical* success of the byte-stream paradigm in UNIX and its adoption by
most OS designs of more recent vintage speaks for itself.

The trouble with your proposed optimization is that it's just one of a crowd
of equally marginal features that, once added, would render the UNIX interface
as cluttered as VMS's without really ever cost-justifying themselves.

Interestingly, some real-time-oriented UNIX versions have a 'write-through'
mode flag for files that will do what you want (disable read-ahead) as a
side-effect. The intent of this is to disable buffer caching for guaranteed
write of precious data -- a feature that is no mere optimization.

> I guess I am starting to diverge.  However, I do believe that there
> are uses for standard access methods that take these things into 
> account.  What I don't understand is why isn't anyone providing them.

Well, by Barry Shein's report, some outfits are. The *interesting* question
is why they're so rarely called for that neither you nor I have ever seen a
commercial product of that kind.

*I* think it's because the byte-stream paradigm *works*...
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718



More information about the Comp.unix.wizards mailing list