Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!pmafire!uudell!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: What does sync() _really_ do?
Message-ID: <18822@rpp386.cactus.org>
Date: 15 Dec 90 15:11:11 GMT
References: <52328@mcdchg.chg.mcd.mot.com> <1635@lot.ACA.MCC.COM>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 54
X-Clever-Slogan: Recycle or Die.

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.

Come on, you worked at IBM for a while, you should have checked
this one out.  Tho, I must confess this is one of the most
interesting theories I've ever heard.

>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.

The way it was explained to me was that all the disk blocks would
be put on the device queues and scheduled for scribbling out.
Once the blocks were sorted, any new requests would be added to
the end of the device queue.  Any further requests for disk I/O
would be on the end of the queue and not satisfied until that
sync was completed.  This ignored that fact that the sync command
should still be in the buffer cache ...

Ron Heiby is probably most accurate in that it was the time
needed to type three sync's in a row that saved most people (and
that it was the time needed to walk over to the Big Red Switch
that saved the rest).  The PDP-11/45 I learned on had blinky
lights - when they stopped blinking I'd push down the HALT switch
and cut the juice (except one time when the console switch was in
the wrong position and I had to call someone and explain that the
HALT switch didn't ...).  Now you can just listen for disk clatter,
if you are unfortunate enough to have noisy disks.  I would feel
my RISC System/6000's cabinet to tell when the disks had stopped
moving.

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

On most System V's it's in sys4.c, with the rest of the bizzare
cruft, like nice(), getuid(), etc.  You can figure out where
the system calls are if you have the kernel libraries.  They
normally live in something like /usr/src/uts/{bzzt}/lib[0-9].a
and can be examined with nm and a good pager.  There is also the
"i" command to ADB for "examining" things. ;-)  SCO Xenix (which
I use at home) puts them in /usr/sys/*/lib*.a, and sys4.o is in
/usr/sys/sys/libsys.a.  The contents of sys[123].c are left to
your imagination, which if suitably warped is probably correct.

Picking up a copy of Bach helps, too.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."