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 540 invoked from network); 5 Jul 2020 20:43:45 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2020 20:43:45 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id EF7F89C6B8; Mon, 6 Jul 2020 06:43:41 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AA72594588; Mon, 6 Jul 2020 06:43:00 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="m6mBh00x"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2BE3E94588; Mon, 6 Jul 2020 06:42:58 +1000 (AEST) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by minnie.tuhs.org (Postfix) with ESMTPS id 73FDE93D46 for ; Mon, 6 Jul 2020 06:42:57 +1000 (AEST) Received: by mail-qt1-f173.google.com with SMTP id b25so6139330qto.2 for ; Sun, 05 Jul 2020 13:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w/q9A9B8M9FO3IUXZBrJ3R4nR+3gAJ0lBnMa63gghhk=; b=m6mBh00xnKmbWtwocCpjpQ76x3lAp22G1JcQrFRqJMr2qubmdM+nu4w+rBnjqOp7Zr lBqI3EGytTOtf5D3SXWcnep2lQzDlKEury2NyCiVoai5W9DTTkSUWpO2VgvgVVAjRzvi FEGbYoYwc3mWNEU15W7BB+HfOoC5VUzstt399hyEHZNwYcLCyvBRqQ1sl3zYc/Qog1l+ 6CVq+c5wWHVCsrz0XkMVN3R36zIu9SSxoM/PFCuqc3CfYudV22nfb54OT6OX2aIgBFeQ 02TBgVB3OTO9UkpmJgqEydAwqlFLOxCvmHGIVSc09+/VhQ8oHZ69tyHpy2RPMoUEJHnB /rog== 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=w/q9A9B8M9FO3IUXZBrJ3R4nR+3gAJ0lBnMa63gghhk=; b=MzPCdn+xdoiv3tdO7Bqycr4GvEUo7MIIxS3z9gPX7Ilk/pSuNib2TIXZMEff5jK58A cMLhAKd7o1gLCEztkEida6WJ8VXUgGnhlyAaAsIy64HuMb2RJkdZq7RPgVVq4ioC6ftb RXULItafImbzhRc0ueZkjsNWYZmD4iVzPGw8mXifylJHc98zI136c6ztE2+CR4yy8m0a rsO0zV9Vk5cVouUJUg8BXKlx33tB7RyUMCd5KS5SPc9+XSBYOFvKHvEGGkYULloybI3q 2MrAwSanhjBm90LDVppV8HhCFr0xuZ+wpPWtw8kj59ABSETJP6RGXXv3+9VNz8pL2fhK LC1w== X-Gm-Message-State: AOAM5324XjQ0LAsh+lW567bVsEGxNak5WRUgTdJJoEHzKErJ77U8ylJ8 qdiQ8hIHNbXpBoQZ826IBSDULnSooYIbZv5BpJlo91djlr4= X-Google-Smtp-Source: ABdhPJwzd5RDTWrQeGHk13z+Mf0v3SIRAp7c3m04zLy6GXpdDOyhtJc7Dwke0O9ldXCj/39vFYil9ZMc+kfMhaMjvj8= X-Received: by 2002:ac8:4c86:: with SMTP id j6mr14103168qtv.56.1593981776540; Sun, 05 Jul 2020 13:42:56 -0700 (PDT) MIME-Version: 1.0 References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> <20200705144332.GR29318@mcvoy.com> In-Reply-To: From: John Cowan Date: Sun, 5 Jul 2020 16:42:45 -0400 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="00000000000091c89d05a9b7cd6a" Subject: Re: [TUHS] VFS prior to 1984 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" --00000000000091c89d05a9b7cd6a Content-Type: text/plain; charset="UTF-8" I always used the design principle "Write locally, read over NFS". This obviated locking issues and fit in with the idea of fate-sharing: a write would always succeed, even if reading would have to wait until R (the machine doing the reading) was up. The only additional thing I needed was the ability for W (the machine doing the writing) to notify R that something had changed, which I did by having R run a process that listened on a port that would be opened and then closed by W: no data flowed over this connection. If this connection could not be made, the process on the W side would loop in bounded exponential backoff. On Sun, Jul 5, 2020 at 4:09 PM Clem Cole wrote: > > > On Sun, Jul 5, 2020 at 10:43 AM Larry McVoy wrote: > >> My guess is that other people didn't understand the "rules" and did >> things that created problems. Sun's clients did understand and did >> not push NFS in ways that would break it. > > I >>believe<< that a difference was file I/O was based on mmap on SunOS > and not on other systems (don't know about Solaris). The error was > handled by the OS memory system. You tell me about how SGI handled I/O. > Tru64 used mmap and I think macOS does also from the Mach heritage. > RTU/Ultrix was traditional BSD. Stellix was SRV3. Both had a file > system cache with write-behind. > > I never knew for sure, but I always suspected that was crux of the > difference in how/where the write failure were handled. But as you > pointed out, many production NFS sites not running Suns had huge problems > with holes in files that were not discovered until it was too late to fix > them. SCCS/RCS repositories were particularly suspect and because people > tried to use them for shared development areas, it could be a big issue. > --00000000000091c89d05a9b7cd6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I always used the design principle "Write locally, re= ad over NFS".=C2=A0 This obviated locking issues and fit in with the i= dea of fate-sharing: a write would always succeed, even if reading would ha= ve to wait until R (the machine doing the reading) was up.=C2=A0 The only a= dditional=C2=A0thing I needed was the ability for W (the machine doing the = writing) to notify R that something had changed, which I did by having R ru= n a process that listened on a port that would be opened and then closed by= W: no data flowed over this connection.=C2=A0 If this connection could not= be made, the process on the W side would loop in bounded exponential backo= ff.=C2=A0

On Sun, Jul 5, 2020 at 4:09 PM Clem Cole <clemc@ccc.com> wrote:


On = Sun, Jul 5, 2020 at 10:43 AM Larry McVoy <lm@mcvoy.com> wrote:
My guess is that other people didn't u= nderstand the "rules" and did
things that created problems.=C2=A0 Sun's clients did understand and di= d
not push NFS in ways that would break it.
I= >>believe<< that a difference was file I/O was based on mmap o= n SunOS and not on other systems (don't know about Solaris).=C2= =A0=C2=A0 The error was handled by the OS memory system.=C2=A0 You tell= me about how SGI handled I/O.=C2=A0 Tru64 used mmap and I think macOS does= also from the Mach heritage.=C2=A0 =C2=A0RTU/Ultrix was traditional BSD.= =C2=A0 Stellix=C2=A0was SRV3.=C2=A0 Both had a file system cache with write-behind.<= /span>

I never knew for sure, but I always suspected that was= crux of the difference in how/where the write failure were handled.= =C2=A0 But as you pointed out, many production NFS sites not running Su= ns had huge problems with holes in files that were not discovered until it = was too late to fix them.=C2=A0 SCCS/RCS repositories were particularly sus= pect and because people tried to use them for shared development areas, it = could be a big issue.
--00000000000091c89d05a9b7cd6a--