[ On Sunday, June 22, 2003 at 02:43:21 (+0700), Robert Elz wrote: ]
> Subject: Re: updating, build and install order 
>
> Note that updlock is cleared inside update() - the sync() sys call doesn't
> return until update() has returned, so updlock has nothing to do with
> consecutive calls of sync() that way - it is (was) there to avoid parallel
> calls of sync from attempting to be executed at the same time.

Ah, yes, of course.

> You need to look deeper than that - and you'll see that the code grabs
> the super block for each mount point then writes it using bwrite(), which
> queues the block to the driver - once the I/O is done, brelse() would
> clear the busy bit.

Yes, but IIUC that's only to schedule the write of the superblock
itself, and unless somehow the writes are ordered such that the
superblock is often/always written last then I would expect this not to
cause the second 'sync' to pause.

> When I look at this again, I'm not quite so sure that the effect of
> this is/was to guarantee that all I/O was done by the time the second
> sync call returned - but I do recall analysing this in much more
> detail in the past, and that was my conclusion then.

You may be correct but I've always assumed that the second sync()
wouldn't find any inodes with any outstanding blocks to call free() on
even though perhaps not all of the previously free()'ed blocks had yet
been actually written to disk.  The first call should have found all the
out-of-date inodes, scheduled their writes, and marked the inodes as
free.  The second and subsequent sync() calls will only schedule just
the re-write the superblock(s) for the mounted filesystem(s).  The only
time the second manual 'sync' should ever pause is if the one triggered
by 'update' was still happening.

I didn't have the root password in those days so I didn't very often get
to actually shut down a machine, though I did help on occasion, and I
watched quite often as well.  I don't remember the second 'sync' command
ever pausing (and this was with a decwriter console probably at 1200bps).
Of course these systems were usually close to quiescent every time I saw
or helped it shutdown because otherwise there'd rarely have been any
reason to reboot it!  ;-)

> If you were just starting, then yes, but if you used one daily for real
> work (or actually, more for a multi-player shoot-em-up game) typing on
> the things was OK - the limiting factor really was the 10 ch/sec.  That
> is, you'd have to wait...

That's simply amazing to imagine!  ;-)

It was weird enough watching people play the space war game on Volker
Craig terminals on the Multics mainframe.  I never got good enough at it
to even come close to competing with those who played it regularly.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>