[ On Wednesday, January 26, 2005 at 15:28:58 (-0500), J Chapman Flack wrote: ]
> Subject: Re: ACPI suspend support. 
>
> I bet (could be wrong) Kernighan and Pike didn't sit down and say
> "let's design a sync that schedules writes but doesn't block on them, and
> then blocks if issued again."  It was probably a simpler idea at first, and
> then didn't get updated for some lower level scheduling change, and some
> people got filesystems hosed and then somebody discovered that two syncs
> would work, and somebody later may have figured out why.

Indeed, if my understanding is correct, the original design goal for
sync(2) was probably _MUCH_ simpler.

The idea, as I understood it, was simply to schedule the writing of
dirty buffers, as otherwise they wouldn't necessarily get written
until/unless the memory they occupied was required for something more
urgent -- and if I understand this correctly that means in a system gone
idle they'd just stay sitting there for as long as the system remained
idle and (except in the case of real core memory) powered up.

The update daemon called sync(2) regularly (in a self-reinstating
30-second alarm() handler) to help ensure that an untimely crash didn't
leave some long ago written data residing only in volatile memory.

As you may know the underlying reason for the three consecutive "sync"
commands was described by kre some time ago:

	http://mail-index.netbsd.org/current-users/2003/06/23/0000.html

However I still suspect from my own reading of the history of how the
whole system grew up into something that could be used reliably, was
that it was only a bit later that someone noticed how a third sync()
call wouldn't complete until the first one's scheduled work had
completed.  This may not even have happened until after the rule about
typing "sync" three times before hitting the reset switch was in
practice, and perhaps only because someone finally managed to type them
fast enough in view of the systems' disks themselves to see that the
prompt didn't come back from the third command until after all the disk
activity stopped.  Only then would someone have been likely to dive into
the code to find out why.


However once kre finally straightened me out on the three sync's lore, I
began to wonder why the sync command didn't just call sync() three times
in a row itself as that would have been the obvious fail-safe way to do
it, and even on a PDP-11, the sync command with three sync() calls
instead of just one would still have been one of the smallest of all
(instead of being _the_ smallest, at least of those implemented in C.  ;-)


That doesn't answer whether or not NetBSD's sync(2) needs to be called
three times in succession to guaranteed a forced flush as sync(8) wishes
to claim, though the hints are that it won't work.  That's something I'd
still like to know for certain, and it seems would also still be
relevant for a proper safe "suspend", assuming vfs_shutdown() isn't
suitable for a suspend.

However since the cpu_reboot() in NetBSD is apparently supposed to call
vfs_shutdown() (and except for amigappc they all seem to) running "sync"
manually, any number of times, before running "halt" or "reboot" is not
(supposed to be) necessary.

Indeed sync(2) and sync(8) seem to be complete anachronisms now!  ;-)

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>