From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1969 invoked from network); 2 Feb 2021 02:31:33 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Feb 2021 02:31:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1924F9B9A8; Tue, 2 Feb 2021 12:31:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B5F2E9B7A0; Tue, 2 Feb 2021 12:31:06 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="mJsSjg+I"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 0947C9B7A0; Tue, 2 Feb 2021 12:31:04 +1000 (AEST) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by minnie.tuhs.org (Postfix) with ESMTPS id A9C0B9B799 for ; Tue, 2 Feb 2021 12:31:00 +1000 (AEST) Received: by mail-qt1-f180.google.com with SMTP id o18so13952396qtp.10 for ; Mon, 01 Feb 2021 18:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fshsnbGIR5SQiXMODg6mw6cv+xWqtndhRi0wAmpJAmw=; b=mJsSjg+IR0ZhoYBTspSoDWxM5DzuW07PxYfgU1jAtdCRJAFEuWPryhbgbGdiq6k9zd LsddbZ4BaKlQMA7+sIdQm9uVM5sM0qWTC76QyBqLLZrQL/oEyN97/LSN3X3S3W4bxEby N4EZ/+fdygebAVw3TVAx8+GnLa3uW7zDkBzEBKH0ztlhHxLM/Oj4E3iaDzFuR4XKp91n BdxMqatK3plrHEcZnwaPaKxaQwXNpmSL1xgEzQGrTLtHrHiQaKfmvBnY3HVrSXDePm0D WALSKYLtrEDAroUAdRtiPjErm5f5L+QBAw0Wy54P+/gGYoS+z4vUUXc/VmRAJIE2e0cb 9KYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fshsnbGIR5SQiXMODg6mw6cv+xWqtndhRi0wAmpJAmw=; b=BUdRXVVn1VzAkoYpCQYRugd+L6mUccH8cMp3fzvvSoDsENXfDFgg0Wc6o2mJzTCwAU TfkCSPTc0OOQVOc9Bmcxcf2QcBFpC7xPXgGo7AgRmPseiyIysvtkXFLuFh6xFa4kpGQk s4EtxquZT9j21RWs3ejuW5DIKdVR+rE/ruM3CkoZ0cjxdknXr+mGLJl3+4rRVUqqbZs4 xTrGXd1JypQyQyUojuOHWDyzazf6qD5rgQma25edFIcCZHmYzSfVeSO/z8juF7gcPlrs 4fnFMDcHu7jFwc0aagYMnlE8D5VyDU77c3S87cnO35Qp4w2y9zIX5gxIJroJfJudtvKl 8KQQ== X-Gm-Message-State: AOAM533XoWMQTlARFuiF6s5APOsVTM0Ff6C9RP5uKdZFrJ/ZJYuuAGXQ UpyErnvzWzMQEMQtn4WTQorMZFEh3eaY4QEeBnXsPLlw3rA= X-Google-Smtp-Source: ABdhPJwI/kxaNnEuQlRv7VzpPEkbryBXHgED01KFvYZoM2xa65kwFJO1vxYQ3A92Z8MHfRLGM56qTGPXdiX46Pz7JHg= X-Received: by 2002:a05:622a:303:: with SMTP id q3mr17692025qtw.235.1612233059379; Mon, 01 Feb 2021 18:30:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 1 Feb 2021 19:30:47 -0700 Message-ID: To: The Unix Heritage Society mailing list Content-Type: multipart/alternative; boundary="000000000000ccbf4b05ba514267" Subject: Re: [TUHS] reboot(2) system call X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ccbf4b05ba514267 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 1, 2021, 7:22 PM Greg A. Woods wrote: > At Sun, 31 Jan 2021 09:27:10 +1100 (EST), Dave Horsfall > 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 > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > --000000000000ccbf4b05ba514267 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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<= br> > > semicolons or not because of the very fact that the second one wo= uld
> > block.
>
> What I was taught was:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0% sync
>=C2=A0 =C2=A0 =C2=A0 =C2=A0% sync
>=C2=A0 =C2=A0 =C2=A0 =C2=A0% sync
>
> and never:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0% 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.=C2=A0 It was trivial to see that the<= br> 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.

Wou= ld be nice to know which one so I can go check. I've not seen leaked xe= nix code though, so it may be possible.=C2=A0

Warner=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg A. = Woods <gwoods@acm.org>

Kelowna, BC=C2=A0 =C2=A0 =C2=A0+1 250 762-7675=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>=C2=A0 =C2=A0 =C2=A0Avoncote Farms = <woods@avoncote.ca>
--000000000000ccbf4b05ba514267--