We should forget about small efficiencies — Donald Knuth
13 Jun
fsync performance, from Gary J’s weblog.
some summary is below:
fsync() is used to ensure that dirty pages that have been written to a file actully go down to disk. The same sort of thing can be done by opening a file using one of the O_SYNC options when a file is opened. fsync() however, allows greater flexibility since the programmer can specify when the synchronisation to disk takes place - perhaps in a separate thread. Anyhow, generally fsync() is goodness and cheap since it only sync’s the data that is dirty.
Since many developers think of fsync() as a ‘free’ system call, often it is called quite indiscriminately and so fsync() performance can really make a BIG difference (See the test results at his weblog).
However there is (or rather was) a subtle problem that shows up when very large files are mapped into the memory of systems with reasonable amounts of memory. The problem is that the file is searched linearly (from beginning to end) from the first page that is mapped in right through to the last.
The good news is that this behavior is changed in Solaris 9 (designed for large systems like the 15/12/25K StarCat range) so that all the dirty pages are put at the head of the list, and we need only search the list until we find the first non-dirty page.
Popularity: 16% [?]
One Response for "Solaris fsync performance"
does fsync() write through the disk cache, right to the surface of the disk?
Leave a reply