This was summarized at MIT’s Project Athena in the mid-80s as: When thou shuttest down the system, thou shalt sync three times. No more, no less. Three shall be the number of the syncing, and the number of the syncing shall be three. Four times shalt thou not sync, neither sync twice, except that thou proceedest to sync a third time. Five is right out. - Win

On Sun, Jan 31, 2021 at 09:27:10AM +1100, Dave Horsfall wrote: I was taught the exact same thing and for the same reasons.

At Sun, 31 Jan 2021 09:27:10 +1100 (EST), Dave Horsfall <dave(a)horsfall.org> wrote: Subject: Re: [TUHS] reboot(2) system call If waiting was the true reason, then any sane person would have put a sleep in there instead so as to avoid any variance in typing (and terminal) speed. On at least a large number of old systems I've used either the first or the second invocation did block and not return if there were still any dirty blocks it made the sync() call. It was trivial to see that the system was busy writing while one waited for the shell prompt to re-appear if one could see the disk activity lights (or hear them) from the console, as was usually easy to do on desktop systems. Since many of those old systems I used were Xenix of one flavour or another, perhaps it was only those that waited for sync I/O to complete. -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>

At Mon, 1 Feb 2021 19:30:47 -0700, Warner Losh <imp(a)bsdimp.com> wrote: Subject: Re: [TUHS] reboot(2) system call Well the first versions I used were on 286 machines, and then 386. I think there may be binaries available in the darker corners (maybe even on archive.org) if one wanted to test empirically on either emulation or real hardware. Maybe someday I could do that, but not soon. On a related note, one of the weird things about Unix System V, from the beginning more or less, and right up to and including the last SysVr4, the shutdown scripts use "sync; sync; sync" all on one line like that (on r4 they use the full path to "/sbin/sync", but still three times). I think on some versions the subsequent call will block briefly while the first call finishes scheduling buffer writes (i.e. the call will wait instead of just returning if another process is in the critical section), they all still just schedule async writes. If I'm not mistaken though calling "sync" in any way at all shouldn't normally be necessary during a proper shutdown as all filesystems, including the root fs, will be unmounted during the process, thus forcing all dirty buffers to be flushed first, and this is in fact the case from SysVr3 and on (i.e. after uadmin(2) with A_SHUTDOWN was introduced). Also, on SysVr4 the fsflush daemon runs as a kernel daemon process, so if I understand correctly it isn't killed during shutdown or in single user mode, thus it'll still be doing the equivalent of sync(2) right up to the end. On the other hand in the particular SysVr4-i386 version I have the code that would actually wait for all async buffer writes during umounts, i.e. in bdwait(), is commented out and replaced by a "delay(200)". I can't imagine why, nor can I imagine trying to debug that without source! -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>