On Mon, 27 Jul 2020, Warner Losh wrote: Seems OK to me; I was taught never to use "sync; sync; sync" for precisely those reasons (the buffers may not have time to flush etc, as "sync" merely schedules the I/O, not cause it. -- Dave

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 Tue, 26 Jan 2021, Greg A. Woods wrote: What I was taught was: % sync % sync % sync and never: % sync; sync; sync The theory was that by waiting for the shell prompt each time, it gave the buffer pool enough time to be flushed. Never heard that theory, but naturally you did a "ps ax" first, didn't you? -- Dave

On Sat, Jan 30, 2021 at 3:32 PM Larry McVoy <lm(a)mcvoy.com> wrote: Yes. There's no actual code in the System V or earlier kernels to block any of the sync calls. At least none I could find in examining all the 'leaked sources' I could find on the internet. sync just schedules I/O. There's nothing in the system call that waits for anything: it just goes through the list of all non-busy buffers calling the driver's strategy routine and marking the buffer as busy. Later systems, like SunOS did have a wait, but that was a later addition, done a half a dozen different ways. BSD had one that waited for a while, but gave up after some tens of seconds... Warner

On Mon, Feb 1, 2021, 7:22 PM Greg A. Woods <woods(a)robohack.ca> wrote: Would be nice to know which one so I can go check. I've not seen leaked xenix code though, so it may be possible. Warner --

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>