The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Greg A. Woods" <woods@robohack.ca>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] reboot(2) system call
Date: Mon, 01 Feb 2021 18:20:57 -0800	[thread overview]
Message-ID: <m1l6lJK-0036x9C@more.local> (raw)
In-Reply-To: <alpine.BSF.2.21.9999.2101310922250.36435@aneurin.horsfall.org>

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

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.

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  parent reply	other threads:[~2021-02-02  2:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 18:57 Warner Losh
2020-07-28  0:36 ` Clem Cole
2020-07-28  4:06 ` Dave Horsfall
2020-07-28 16:35   ` Win Treese
2020-07-28 13:11 ` Jaap Akkerhuis
2021-01-27  6:01 ` Greg A. Woods
2021-01-30 22:27   ` Dave Horsfall
2021-01-30 22:31     ` Larry McVoy
2021-01-30 22:37       ` Warner Losh
2021-02-02  2:20     ` Greg A. Woods [this message]
2021-02-02  2:30       ` Warner Losh
2021-02-02 20:30         ` Greg A. Woods
2021-02-02  3:35       ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1l6lJK-0036x9C@more.local \
    --to=woods@robohack.ca \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).