What does sync() _really_ do?

[Piercarlo Grandi]

On 26 Dec 90 16:54:55 GMT, dkeisen at Gang-of-Four.Stanford.EDU (Dave
Eisen) said:

dkeisen> In article <PCG.90Dec22171527 at odin.cs.aber.ac.uk>
dkeisen> pcg at 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 at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk