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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1763 invoked from network); 30 Jan 2021 22:37:33 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2021 22:37:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 515219C7F9; Sun, 31 Jan 2021 08:37:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E289B9C653; Sun, 31 Jan 2021 08:37:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="LCxScM1T"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 05B509C653; Sun, 31 Jan 2021 08:37:16 +1000 (AEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 01A239C63D for ; Sun, 31 Jan 2021 08:37:15 +1000 (AEST) Received: by mail-qt1-f169.google.com with SMTP id c1so9564620qtc.1 for ; Sat, 30 Jan 2021 14:37:14 -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 :cc; bh=bKNNeGXNlhvepCooD8VyrSysNLBpiEz3N+EulqWP/tE=; b=LCxScM1TKVMXi+I20xlbKM9vHAv+yl2vCg7ds7v8+BjS5VEHsL2BRsoTZZXw0eE6Rc /X8wQuS7xOAvau2iqE5hODi1bsIg6GZvPkxWsg8zOCFiKFBa/2QarJRyvo8KOx3nvjMc BDjARvH79Xl7KlPNVeixu85aLFN+L421B8ox7/SIK1bamLmcFuQ9kCCh/d8MTBOazTyQ NPkosWexFB88oVKDrtmDXPEAkX9LoF2WKtvn5IgMTsMSjFJPAURvU1/soE6lUcjlgcjX RSvRtaTK6PS22MeD0U9KLA9lHnqyHEpe+UrZc1WtRt9AnkyW3PdQCLAs9R8QXvPSpi6l aXAg== 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:cc; bh=bKNNeGXNlhvepCooD8VyrSysNLBpiEz3N+EulqWP/tE=; b=MMHy9BsrC1r8dS3lMUx5yaex2DLFTxtyGn+db7psuarSMYj+c2PXBNO8LNu28P2UYY 3znQoMF2OAc6Ftw5/fPrztOXlai0PMETB+ZV8SI8U8a/A1HfSFWuMmUizjrcbemw2+B4 aXAKnE3JLFaD9TM1hDek/KUi96rWckTiD1qQznThdNjzL/bDSq1YfD/I3uKIN2Q9N8YS VJAw9LqoIxfTU8dX4IWT3hw0rU5eXQ4xaFuaZMtZnpaVAfrec9s92P4XjmfJyzouEU++ Fprlms2J3Y5KIDgmL6quHNiBDSm93fDVjQzvTxl+CvtTXJqLXvJC+qZi7Y5f55n/vbv0 2oag== X-Gm-Message-State: AOAM531bedQpT04mpzmW85Wfm2/KuqOC/foXilslZLITyYmyIi8JL+rw Xnki6dSkNxmxZDHXnuXQO3y68DvlkxcxDeRsWDw2nSrfw57MJQ== X-Google-Smtp-Source: ABdhPJzxFHrhRKEqZQLCg3baHDfyO1eWIBP7Kl2Udwx84qnBxOoi9XEauwnCTv60JuI6ZlrKB1uEVQZ4NHBatpf5mWs= X-Received: by 2002:aed:2de2:: with SMTP id i89mr9701076qtd.73.1612046233866; Sat, 30 Jan 2021 14:37:13 -0800 (PST) MIME-Version: 1.0 References: <20210130223154.GP4227@mcvoy.com> In-Reply-To: <20210130223154.GP4227@mcvoy.com> From: Warner Losh Date: Sat, 30 Jan 2021 15:37:02 -0700 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="00000000000021a8d005ba25c3fd" 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: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000021a8d005ba25c3fd Content-Type: text/plain; charset="UTF-8" On Sat, Jan 30, 2021 at 3:32 PM Larry McVoy 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 --00000000000021a8d005ba25c3fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 30, 2021 at 3:32 PM Larry= McVoy <lm@mcvoy.com> wrote:
<= /div>
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 semicolon= s or not
> >because of the very fact that the second one would 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.

I was taught the exact same thing and for the same reasons.

Yes. There's no actual code in the System V or ear= lier 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=C2=A0I/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 w= ays. BSD had one that waited for a while, but gave up after some tens of se= conds...

Warner=C2=A0
--00000000000021a8d005ba25c3fd--