[TUHS] sync; sync; sync; halt (was: Re: Illumos ))

[Tom Ivar Helbekkmo]

Dave Horsfall <dave at horsfall.org> writes:

> It was drilled into us that the correct usage was:
>
> # sync
> # sync
> # sync
>
> This gives the disk buffers time to actually flush (the writes were merely 
> scheduled, and were asynchronous).

There is another reason why multiple syncs before halting the system
were needed.  There was no fancy I/O order juggling, so everything was
written in the same chronological order as it was scheduled.  If you
look at 6th edition source code, you'll find that a call to sync would
invoke the internal routine update(), which does three things in order:

1: schedule writes of superblocks, and wait for them to complete
2: update in-memory inode time stamps wherever needed
3: schedule writes of inodes and data blocks that are now dirty

What this means is that the second sync, by waiting for its own
superblock writes, will wait until all the inode and file data flushes
scheduled by the first one have completed.

What I haven't been able to figure out from a few minutes studying the
code, is whether the third sync is really needed, or just a "belt and
suspenders" thing.  I've heard it claimed that the flushing of inodes
and/or file data going on while the second sync is waiting for its
already scheduled superblock writes to complete will cause the third one
to be needed.  That would mean either that flushing dirty file blocks
could cause inode updates, or that flushing inodes could cause
superblock updates.  Anyone know the internals well enough to say?

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"