2 Feb
2021
2 Feb
'21
8:20 a.m.
At Sun, 31 Jan 2021 09:27:10 +1100 (EST), Dave Horsfall <dave(a)horsfall.org> wrote:
Subject: Re: [TUHS] reboot(2) system call
On Tue, 26 Jan 2021, Greg A. Woods wrote:
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>
The lore I was told at the time was that you
alwasy ran three and
that it didn't matter if they were all on the same line with
semicolons or not because of the very fact that the second one would
block.
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.