What does sync() _really_ do?

[Ron Heiby]

steinar at ifi.uio.no (Steinar Kj{rnsr|d) writes:

>The disk vendor's assumption is that
>the three sync() calls will guarantee that the read pass of the test will
>read data  off the media, not from the buffer cache, while I say that
>although the sync() calls force dirty pages in the buffer cache to be written
>to the disk, you have no guarantee that those pages also will be wiped out
>from the cache.

>Who are right?

My experience is with System V derived releases, but I find it hard to
believe that bsd would be different in this.  You are right.  All a
sync(2) call does is queue all the dirty pages to be written to the
disk.  As far as I know, there is no guarantee that they actually
*have* been written when the sync(2) call returns, just that they've
all been *queued* to be written.

Also, there's no reason to have a line of the form
"sync();sync();sync()" in a C program, just as there is no reason to
have a line of the form "sync;sync;sync" in a shell script.  One is
quite sufficient.  The reason one sees three is that the way to shut
down earlier UNIX systems was to change to single-user mode, then (at
single user prompt) type sync three times.  This was not done as:
	# sync;sync;sync
(except by people who didn't understand).  It was done as:
	# sync
	# sync
	# sync
The theory was that by the time the operator typed the third command,
the disk blocks queued for writing by the first had had sufficient
time to actually be written to the disk.  In the former case, with all
three on a single line, there's really no time delay between the first
"sync" and the third, so no chance for the disk blocks to be written.
What saved most people doing it that way was that it took them a
couple of seconds to get up and hit the reset or power switch.
-- 
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!!!"