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 --]
next prev parent 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).