Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!opal!tmpmbx!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.internals
Subject: Re: What does sync() _really_ do?
Message-ID: <1990Dec20.141627.21202@scuzzy.in-berlin.de>
Date: 20 Dec 90 14:16:27 GMT
References: <52328@mcdchg.chg.mcd.mot.com> <1635@lot.ACA.MCC.COM> <5156@segue.segue.com> <4670@pkmab.se>
Organization: Contributed Software
Lines: 24

ske@pkmab.se (Kristoffer Eriksson) writes:

>In article <5156@segue.segue.com> jim@segue.segue.com (Jim Balter) writes:
>>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.

>When I type "sync" once after some disk writing activity on my system,
>there is a delay before I get the prompt back. If that delay is not caused
>by sync() waiting for disk blocks to be written, then I wonder what it is
>caused by. How do your systems act? Do they give you any delay?

at least with interactive unix there is a little delay before you get
the prompt back. the delay is caused by the kernel queuing the transfers.
however, those three syncs often 'advertised' might not suffice to fully 
flush the dirty buffers in time. i.e. after processing incoming news, there
can be a *lot* dirty buffers to be written. with slow disks, that are often
used for /usr/spool/news, this can cause the time to flush all buffers to
be well over 5 seconds. so one should have a look at the drives' LEDs to
see if it's save to hit the red one.
-- 
      Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home