Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mtxinu!shore
From: shore@mtxinu.COM (Melinda Shore)
Newsgroups: comp.unix.internals
Subject: Re: What does sync() _really_ do?
Message-ID: <1990Dec17.022908.29929@mtxinu.COM>
Date: 17 Dec 90 02:29:08 GMT
References: <52328@mcdchg.chg.mcd.mot.com> <1635@lot.ACA.MCC.COM>
Reply-To: shore@mtxinu.com (Melinda Shore)
Organization: mt Xinu, Berkeley
Lines: 24

In article <1635@lot.ACA.MCC.COM> ables@lot.ACA.MCC.COM (King Ables) writes:
>From article <52328@mcdchg.chg.mcd.mot.com>, by heiby@mcdchg.chg.mcd.mot.com (Ron Heiby):
>> 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.  
>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.

No, Ron was correct (remember the old pop song "Sync 3 Times on the
Ceiling If You Want Me?").  The convention really was for the purpose
of allowing time for the write.

To the original poster, the reason for doing a sync even if you don't
need buffers is to ensure data integrity;  you do want to maximize the
likelihood that the cache contents are consistent with the state of the
disk in the event of a crash.  /etc/update syncs every 30 seconds, so
it's pretty unusual to need to do a sync in a user program.
-- 
               Hardware brevis, software longa
Melinda Shore                                 shore@mtxinu.com
mt Xinu                              ..!uunet!mtxinu.com!shore