Re: [TUHS] reboot(2) system call

[Warner Losh <imp@bsdimp.com>]

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

On Sat, Jan 30, 2021 at 3:32 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sun, Jan 31, 2021 at 09:27:10AM +1100, Dave Horsfall wrote:
> > 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.
>
> I was taught the exact same thing and for the same reasons.
>

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

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