Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!lot!ables
From: ables@lot.ACA.MCC.COM (King Ables)
Newsgroups: comp.unix.internals
Subject: Re: What does sync() _really_ do?
Message-ID: <1635@lot.ACA.MCC.COM>
Date: 14 Dec 90 22:44:30 GMT
References: <52328@mcdchg.chg.mcd.mot.com>
Organization: MCC ACT Program, Austin, TX
Lines: 41

From article <52328@mcdchg.chg.mcd.mot.com>, by heiby@mcdchg.chg.mcd.mot.com (Ron Heiby):
> steinar@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.
> 
> 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.

The way I understood it was that when sync() got called, it
put a request in a sync queue to have the kernel flush out
the unwritten disk blocks and then returned.  When a second sync()
call was made, it added it's request to the queue, and so on.

The secret was supposed to be that the queue had only two slots
it, thus a 3rd sync() call couldn't return having successfully
put its request in the queue until the first sync request had
been processed and removed from the queue.  So when the 3rd
one returned, you knew the first one had actually happened.

I never actually looked at the code, but it was the most acceptable
explanation I ever heard.  It was also from a source I didn't have
cause to doubt, but I don't remember where I picked it up now.

For what it's worth... hmmm... where is sync.c, anyway...  ;-)

-----------------------------------------------------------------------------
King Ables                    Micro Electronics and Computer Technology Corp.
ables@mcc.com                 3500 W. Balcones Center Drive
+1 512 338 3749               Austin, TX  78759
-----------------------------------------------------------------------------
We don't inherit the Earth from our parents, we borrow it from our children.