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 29406 invoked from network); 5 Jul 2020 20:09:57 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2020 20:09:57 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4E30C9C72B; Mon, 6 Jul 2020 06:09:55 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DAEBF94588; Mon, 6 Jul 2020 06:09:08 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="aB448vwD"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 61BAE94588; Mon, 6 Jul 2020 06:09:06 +1000 (AEST) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by minnie.tuhs.org (Postfix) with ESMTPS id C360A93D46 for ; Mon, 6 Jul 2020 06:09:05 +1000 (AEST) Received: by mail-qt1-f174.google.com with SMTP id x62so27533303qtd.3 for ; Sun, 05 Jul 2020 13:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3vlivFfJNHXQLoEcuKVVRFovruIs0yhv3G6ZxjhEzrE=; b=aB448vwDq+DhR60IsV6Pxzopt+XX1BXAdR20h1gSkC6ZWuctHqIrWfjhJMY+mN0shf ZbOYbIHw8OhEtDsp1clyu5JEa8WUDj59BM09u8aummlx+b/YnJG0xthA7oE1VRB6B9ND Dz2ZKL28/PZcDOScLf4du1sUoagf97OK3HZ6E= 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=3vlivFfJNHXQLoEcuKVVRFovruIs0yhv3G6ZxjhEzrE=; b=t/zFUIA7e0bxQRKq07buOKTIG92+QSG1X33OCAnXupgyl9PQRSw9EupnrXv35xzw7v Z5pdNR0qI0WVHQRmbXuaEY/kj/wQsRM95hBfx4pWQ2K/pZ1fSDt0z7T8j61g32RIZ/5X /2RXj0lbYohfY71FPAYte1uT4f4xN/qzL7xJfDnpxJ0qBUZi9ZHQwbEAeYRVXuOvK9sg I4XwuRoSL1qOV8fV+WmE4pzO0pnua3XD3Ry0X78MWehD1Jf5L62bRWsjM8HgQ7968wvn jYwfB9gbPpSPNwYNG/nLUJy3njNeVMeKTWYTQoFYJQG0LQgBX2i4dCG9f0r2yVer5mq9 5A5A== X-Gm-Message-State: AOAM532XaXPZJAg+4RhqGQ6YzmpM6OyIbXtrl4LAnghsUutO/taRehom ZBqWoK2PSQmq73I1NnPvNytOSSssRqZlwdZ3+3IOHGlCoHw= X-Google-Smtp-Source: ABdhPJyF2MC6CIuCB4crTbygRnA+N8WlKSQ6NOEiRVqpRNAKx+e+ybBjdPSmrgNu1NcqDeBY0MQc9wOMs2bwaDqbzrU= X-Received: by 2002:aed:26e1:: with SMTP id q88mr47929825qtd.354.1593979744607; Sun, 05 Jul 2020 13:09:04 -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: <20200705144332.GR29318@mcvoy.com> From: Clem Cole Date: Sun, 5 Jul 2020 16:08:39 -0400 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="00000000000074f2ae05a9b754c1" 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" --00000000000074f2ae05a9b754c1 Content-Type: text/plain; charset="UTF-8" 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. --00000000000074f2ae05a9b754c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 5, 2020 at 10:43= AM Larry McVoy <lm@mcvoy.com> wr= ote:
My guess is= that other people didn't understand 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.
--00000000000074f2ae05a9b754c1--