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 26915 invoked from network); 5 Jul 2020 14:44:24 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2020 14:44:24 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 313E19C72B; Mon, 6 Jul 2020 00:44:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 42E209C5F1; Mon, 6 Jul 2020 00:43:38 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 727739C5F1; Mon, 6 Jul 2020 00:43:34 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 8B5F59C5E1 for ; Mon, 6 Jul 2020 00:43:33 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 051BA35E13B; Sun, 5 Jul 2020 07:43:32 -0700 (PDT) Date: Sun, 5 Jul 2020 07:43:32 -0700 From: Larry McVoy To: Clem Cole Message-ID: <20200705144332.GR29318@mcvoy.com> References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> <20200623140124.GR22291@mcvoy.com> <20200624193647.GB14302@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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" On Sat, Jul 04, 2020 at 09:43:04PM -0400, Clem Cole wrote: > On Sat, Jul 4, 2020 at 8:07 PM Dave Horsfall wrote: > > > Aren't holes part of the file system semantics? > > > Exactly - and that was the problem with NFS. Consider two write > operations. Remember each op is a complete operation with a seek to where > it's going. If the first fails, but the error is not reported (NFS returns > errors on close), the second operations seek over the failed write -- UNIX > puts zeros in the file. File closes later and the size is fine of > course. Oh yeah, whoever bothered to check for errors on close (like the > traditional SCCS or RCS commands)? > > Later to try to read your file back -- it will have a bunch of zeros. So I've encountered lots of holes in NFS files where there shouldn't be any. So it is/was a thing. But that said, I can't remember a single case of encountering that on Sun's campus. I don't know if my memory is failing me, but I do know that when I left Sun and started working with other NFS implementations, yeah, lots of problems. Somehow Sun got it right where other people didn't. The point I'm trying to make is that I don't think NFS was broken by design, it worked when it was Sun servers and Sun clients. Sun's entire campus, 10's of thousands of machines, used NFS. Sun would have screeched to a halt if NFS didn't work reliably all the time. So it was possible to get it to work. 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. My memory may not be the greatest but I can still remember being astonished when I first ran into people saying NFS didn't work. It worked great for Sun and Sun's customers.