Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.internals
Subject: Re: What does sync() _really_ do?
Message-ID: <5156@segue.segue.com>
Date: 15 Dec 90 21:18:21 GMT
References: <52328@mcdchg.chg.mcd.mot.com> <1635@lot.ACA.MCC.COM>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 23


In article <1635@lot.ACA.MCC.COM> ables@lot.ACA.MCC.COM (King Ables) writes:
>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.

If one insists on believing that people are being rational in typing sync
three times, that's a great hypothesis.  However, it has no basis in fact.
While there may a such a sync queue in some kernel somewhere, there isn't one
in any of the common kernels that have had triple syncs directed at them.
(Gee, I hope I haven't violated a non-disclosure agreement by saying so.)

[This paragraph has been placed here to satisfy some incredibly stupid person
who coded inews to reject insufficiently lengthy new articles.
Oh, that wasn't the intent of the check?  Like I said, incredibly stupid.
IMHO, of course.]