Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Re: What does sync() _really_ do? Message-ID: Date: 31 Dec 90 12:57:58 GMT References: <341@cti1.UUCP> <1990Dec26.165455.9315@Neon.Stanford.EDU> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 60 Nntp-Posting-Host: teachk In-reply-to: dkeisen@Gang-of-Four.Stanford.EDU's message of 26 Dec 90 16:54:55 GMT On 26 Dec 90 16:54:55 GMT, dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) said: dkeisen> In article dkeisen> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> Yep. The *only* portable way to make sure that the buffers ^^^^^^^^ pcg> associated to a file's block are freed is to unmount the filesystem pcg> on which the file resides. dkeisen> Is unmounting a filesystem an easier way than doing enough dkeisen> reads from other parts of the disk to overwrite all of the dkeisen> buffers in the cache? The answer is YES. Note the emphasis above. Less tersely: Just to state the obvious: "doing enough reads" to swamp the cache is not guaranteed to work, because whether it swamps the cache depends on the buffer replacement strategy, and on whether file access is memory mapped or not, and many other considerations. For example assume that you have a 1000 buffer cache and you quickly read sequentially 1001 blocks. This may work if the cache manager ages buffer blocks more slowly than you read them in, it may not work if the cache manager recognizes the sequential access pattern. You can read 1001 blocks at random, this may work is the cache manager is strictly LRU, it may not work is the cache manager is not stupid (most are though) and recognizes the access pattern. In practice you can rely on the replacement algorithm to be some kind of LRU, but me, being a fairly silly guy, would not presume to be able to reverse engineer it and devise a synthetic caching algorithm frustration reference pattern. It could be a Master or even Doctoral research project to write a program that when run under UNIX exercises the cache manager to reverse engineer its replacement policy and then calculates a reference pattern that frustrates it reliably and portably. There are several suble problems... You are welcome to try! But I'd rather advance one humble suggestion: Unix systems are very weak as to VM algorithms and tuning tools. It might be much more useful and easier putting in something better than the appallingly deficient VM algorithms of too many of today's Unix variants (System V.3.2 still does expansion swaps! And it is proudly documented in Bach's book too!) and to provide memory profilers to analyze the reference patterns of user programs and increase locality, so for example more people would understand how poorly implemented are things like the MIT X server and GNU Emacs. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk