What does sync() _really_ do?

[Ron Heiby]

ske at pkmab.se (Kristoffer Eriksson) writes:

>When I type "sync" once after some disk writing activity on my system,
>there is a delay before I get the prompt back. If that delay is not caused
>by sync() waiting for disk blocks to be written, then I wonder what it is
>caused by. How do your systems act? Do they give you any delay?

I've noticed that, too.  My explanation is that when you type the
first sync command, there are a potentially large number of dirty
buffers, so there is a lot of work that that system call has to do.
Lots of buffers need to be put onto the write queue for your disks.
The second and third sync commands find relatively few dirty buffers.
In fact, if you are in single-user mode, it probably finds none.  So,
there isn't much work to be done.  Also, as soon as those blocks start
getting written, your system has a burst of activity in terms of i/o
driver code, including interrupt code, to continue to keep it busy.

On the subject of the "every 30 seconds" sync - we found at Motorola
that as buffer caches increase in size, the amount of time spent once
or twice a minute to flush the entire cache of dirty buffers to disk
was beginning to be noticeable to our customers.  Our current 68K and
88K releases of System V provide tunables to control this.  The
default settings cause 1/60th of the buffer cache to be flushed to
disk each second.  Spreading the load of writing the dirty buffers
gives much smoother performance.
-- 
Ron Heiby, heiby at chg.mcd.mot.com	Moderator: comp.newprod
"Give me voice mail or give me drugs!"/"Mandatory Drug Testing? Just Say NO!!!"