Xref: utzoo comp.unix.wizards:11677 comp.lang.c:13226 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!mirror!rayssd!raybed2!cvbnet2!aperez From: aperez@cvbnet2.UUCP (Arturo Perez Ext.) Newsgroups: comp.unix.wizards,comp.lang.c Subject: Re: Record-access libraries (with query on NFS) Message-ID: <287@cvbnet2.UUCP> Date: 10 Oct 88 16:50:15 GMT References: Sender: postnews@cvbnet2.UUCP Lines: 48 From article , by eric@snark.UUCP (Eric S. Raymond): > In article <258@cvbnet2.uucp>, aperez@blazer.uucp (Arturo Perez Ext.) writes: >> 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? > > 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* think it's because the byte-stream paradigm *works*... Oh, I quite agree that the byte-stream paradigm works. That isn't the gist of my question. In retrospect, it is obvious that the reason no one is providing record access libraries is because it is too easy to "roll your own." The UNIX file system paradigm is very powerful and very flexible; obviously, if you can access a byte then you can access any number of them and treat that larger aggregate as a record. However, it is true that the kernel's read-ahead, write-behind philosophy can sometimes get in the way, especially for things like critical databases where you want to be able to guarantee when the data is written to disk. If you access the raw disk device do you disable that read-ahead and write-behind aspect of the UNIX filesystem abstraction? And, in another vein, why does Sun's NFS (latest version notwithstanding) disable that write-behind? Isn't enough for the kernel to say "Yeah, I got the data" since that's the only guarantee you get in the normal case anyway (i.e. with write-behind, you pass the data to the kernel with write() and eventually it makes it to the actual disk). Why does Sun's NFS require the server to wait for the data to actually be on the disk before responses are sent to client? It makes for slow data transfers... Arturo Perez ComputerVision, a division of Prime primerd!cvbnet!aperez The difference between genius and idiocy is that genius has its limits.