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=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 843 invoked from network); 2 Feb 2021 02:21:49 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Feb 2021 02:21:49 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 667339C79F; Tue, 2 Feb 2021 12:21:47 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 438799B7A0; Tue, 2 Feb 2021 12:21:04 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 74F4B9B7A0; Tue, 2 Feb 2021 12:21:01 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id 09F829B799 for ; Tue, 2 Feb 2021 12:21:00 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)d207-6-82-137.bchsia.telus.net[207.6.82.137] port=64849) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (4098 bytes) (sender: ) (ident using UNIX) id for ; Mon, 1 Feb 2021 21:20:58 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)xentastic.local[10.0.1.140] port=64880) by more.local([10.0.1.129] port=25) via TCP with esmtp (3593 bytes) (sender: ) id for ; Mon, 1 Feb 2021 18:20:58 -0800 (PST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Mon, 01 Feb 2021 18:20:57 -0800 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Mon_Feb__1_18:20:40_2021-1 Content-Type: text/plain; charset=US-ASCII 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. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Mon_Feb__1_18:20:40_2021-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCYBi2+wAKCRBie18UwlnH hUt+AJ96zxp0FysDGsMB+Htb1pZOLhD9EACggBbtNq/EPzWv1maD+rZhycOx+EM= =36It -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Feb__1_18:20:40_2021-1--