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 30554 invoked from network); 5 Jul 2020 00:17:15 -0000
Received: from minnie.tuhs.org (45.79.103.53)
  by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2020 00:17:15 -0000
Received: by minnie.tuhs.org (Postfix, from userid 112)
	id 233B29C746; Sun,  5 Jul 2020 10:17:11 +1000 (AEST)
Received: from minnie.tuhs.org (localhost [127.0.0.1])
	by minnie.tuhs.org (Postfix) with ESMTP id AD3C09C6AE;
	Sun,  5 Jul 2020 10:16:12 +1000 (AEST)
Received: by minnie.tuhs.org (Postfix, from userid 112)
 id 9C5C99C5E1; Sun,  5 Jul 2020 10:16:10 +1000 (AEST)
Received: from mcvoy.com (mcvoy.com [192.169.23.250])
 by minnie.tuhs.org (Postfix) with ESMTPS id 2537494585
 for <tuhs@tuhs.org>; Sun,  5 Jul 2020 10:16:10 +1000 (AEST)
Received: by mcvoy.com (Postfix, from userid 3546)
 id 9CAFB35E13B; Sat,  4 Jul 2020 17:16:09 -0700 (PDT)
Date: Sat, 4 Jul 2020 17:16:09 -0700
From: Larry McVoy <lm@mcvoy.com>
To: Dave Horsfall <dave@horsfall.org>
Message-ID: <20200705001609.GO29318@mcvoy.com>
References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl>
 <20200623140124.GR22291@mcvoy.com>
 <CAC20D2OkGKj58=XPcPW+NoAXE3i+_mRSeBD-oJUY36FSdBBd5A@mail.gmail.com>
 <20200624193647.GB14302@mcvoy.com>
 <alpine.BSF.2.21.9999.2007050939520.455@aneurin.horsfall.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.21.9999.2007050939520.455@aneurin.horsfall.org>
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 <tuhs.minnie.tuhs.org>
List-Unsubscribe: <https://minnie.tuhs.org/cgi-bin/mailman/options/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=unsubscribe>
List-Archive: <http://minnie.tuhs.org/pipermail/tuhs/>
List-Post: <mailto:tuhs@minnie.tuhs.org>
List-Help: <mailto:tuhs-request@minnie.tuhs.org?subject=help>
List-Subscribe: <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=subscribe>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

On Sun, Jul 05, 2020 at 10:05:57AM +1000, Dave Horsfall wrote:
> On Wed, 24 Jun 2020, Larry McVoy wrote:
> 
> >>In the end, early NFS was notorious for putting 'holes' in the files
> >>because of the automatic seek in every operation and errors not coming
> >>until close(2) time.
> >
> >You have no idea how many of those holes that 16 bit SCCS checksum has
> >found (BitKeeper kept it).
> 
> Aren't holes part of the file system semantics?  

I'm not talking about legit holes, I'm talking about where your data used
be served up as a list of zeros.

The SCCS checksum is weak but kinda handy.  You could see single bit errors
with it (at least you could in BitKeeper).  It would say 

checksum error: wanted %d, got %d

and you could look at the numbers and see that it was one bit off.

We found a bunch of those because computers used to be ECC or parity and
then 15 years ago or so, they just dumped the parity bit so single bit
errors go unreported (noice, computer industry).