Xref: utzoo comp.unix.wizards:11545 comp.lang.c:13100 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!nrl-cmf!cmcl2!rutgers!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.unix.wizards,comp.lang.c Subject: Re: Record-access libraries (Was: Re: VMS vs. UNIX file system) Message-ID: Date: 5 Oct 88 15:32:59 GMT References: <258@cvbnet2.uucp> Organization: Benevolent Space Xist Retirement Home Lines: 39 Back-References: <5722@killer.dallas.tx.us> In article <258@cvbnet2.uucp>, aperez@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@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718