Re: [TUHS] reboot(2) system call

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Mon, Feb 1, 2021, 7:22 PM Greg A. Woods <woods@robohack.ca> wrote:

> At Sun, 31 Jan 2021 09:27:10 +1100 (EST), Dave Horsfall <dave@horsfall.org>
> wrote:
> Subject: Re: [TUHS] reboot(2) system call
> >
> > On Tue, 26 Jan 2021, Greg A. Woods wrote:
> >
> > > 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.
>
> 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.
>

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

--
>                                         Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>
>

[-- Attachment #2: Type: text/html, Size: 3037 bytes --]