The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: John Cowan <cowan@ccil.org>
To: Clem Cole <clemc@ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] VFS prior to 1984
Date: Sun, 5 Jul 2020 16:42:45 -0400	[thread overview]
Message-ID: <CAD2gp_RBRHrnWAWLi8TrVaD=RLfs+4wxE6eTci_0zF=gFG5apQ@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2PZa2RNiRXbBfnzDPTKtGgVfRg0UW4ur5tAdFtynNzJ+w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

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 <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 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.
>

[-- Attachment #2: Type: text/html, Size: 3290 bytes --]

  reply	other threads:[~2020-07-05 20:43 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  9:09 Paul Ruizendaal
2020-06-23 14:01 ` Larry McVoy
2020-06-23 15:12   ` Clem Cole
2020-06-23 15:55     ` Rich Morin
2020-06-23 20:38     ` Rob Pike
2020-06-23 20:57       ` Larry McVoy
2020-06-24  5:14       ` arnold
2020-06-24 21:08         ` Dave Horsfall
2020-06-24 19:30       ` Clem Cole
2020-06-24 19:36     ` Larry McVoy
2020-06-25  6:52       ` Rob Gingell
2020-07-05  0:05       ` Dave Horsfall
2020-07-05  0:16         ` Larry McVoy
2020-07-06  4:42           ` Dave Horsfall
2020-07-06 16:51           ` Chris Torek
2020-07-06 23:23             ` [TUHS] ECC memory John Gilmore
2020-07-07  1:07             ` [TUHS] VFS prior to 1984 Bakul Shah
2020-07-05  1:43         ` Clem Cole
2020-07-05 14:43           ` Larry McVoy
2020-07-05 18:40             ` Arthur Krewat
2020-07-05 20:08             ` Clem Cole
2020-07-05 20:42               ` John Cowan [this message]
2020-07-05 21:04                 ` Clem Cole
2020-07-05 21:14                   ` Dan Cross
2020-06-24 16:51 ` Anthony Martin
2020-06-24 17:31   ` Anthony Martin
2020-06-24 18:31   ` Paul Ruizendaal
2020-06-25  0:56     ` Rob Gingell via TUHS
2020-06-25  4:15       ` [TUHS] Oh, things were very different Rich Morin
2020-06-25 15:45         ` Lawrence Stewart
2020-06-25 16:24           ` Warner Losh
2020-06-25 17:57           ` Arthur Krewat
2020-06-25 20:22         ` Dave Horsfall
2020-06-25 20:42           ` Michael Kjörling
2020-06-25 20:49           ` Clem Cole
2020-06-26  0:48             ` Dave Horsfall
2020-06-24 19:05   ` [TUHS] VFS prior to 1984 Paul Ruizendaal
2020-06-24 20:27 ` Derek Fawcus
2020-06-24 21:33 ` Greg A. Woods
2020-06-25  0:45   ` Adam Thornton
2020-06-25 19:40     ` Greg A. Woods
2020-06-23 22:17 Norman Wilson
2020-06-23 22:24 ` Dave Horsfall
2020-06-24  4:09   ` Warner Losh
2020-06-24  5:10     ` Dave Horsfall
2020-06-24  5:33       ` Bakul Shah
2020-06-24  9:10         ` Andrew Warkentin
2020-06-24 14:31 Noel Chiappa
2020-06-24 15:21 ` Clem Cole
2020-06-24 17:51 Noel Chiappa
2020-06-24 18:13 ` Richard Salz
2020-06-24 18:46   ` Lars Brinkhoff
2020-06-24 18:31 Norman Wilson
2020-06-25  6:22 ` arnold
2020-06-25 19:31 Noel Chiappa
2020-06-25 20:23 Noel Chiappa
2020-06-25 20:25 Noel Chiappa
2020-06-26  5:49 ` Lars Brinkhoff
2020-06-26  8:34   ` Dave Horsfall
2020-06-26 11:13     ` arnold
2020-06-29  9:11 Paul Ruizendaal
2020-06-29 14:45 ` Larry McVoy
2020-06-29 14:53   ` Paul Ruizendaal
2020-06-29 15:14     ` Larry McVoy
2020-06-29 16:34 ` Heinz Lycklama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD2gp_RBRHrnWAWLi8TrVaD=RLfs+4wxE6eTci_0zF=gFG5apQ@mail.gmail.com' \
    --to=cowan@ccil.org \
    --cc=clemc@ccc.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).