The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Interesting commentary on Unix from Multicians.
Date: Sat, 9 Apr 2022 09:09:10 -0400	[thread overview]
Message-ID: <CAEoi9W4Y1R28mg4uFy_=4H1h_ufcwrgSi0Yn9YxjorwQ6JehKw@mail.gmail.com> (raw)
In-Reply-To: <YlF3rb2m+AUfCPfj@mit.edu>

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

On Sat, Apr 9, 2022, 8:18 AM tytso <tytso@mit.edu> wrote:

> On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote:
> > Single Level Storage is an awesome concept and removes so many ugly
> > hacks from algorithms that otherwise have to process data in files.
> > Doing data processing with read and write and pipes is effectively
> > working through a straw whereas SLS allows all (reasonably sized) data
> > to be presented in entirely complete randomly accessible arrays just by
> > attaching a "file" to a segment.  Mmap() is a very poor replacement that
> > requires a great deal extra bookkeeping that's next to impossible to
> > hide from; and also there's the problem of the consistency semantics
> > being different between the I/O based filesystems and direct memory
> > mapping of their files, which Mmap() reveals, and which SLS eliminates
> > (by simply not having any I/O mechanism for files in the first place!).
>
> To be fair, Multics had it a lot easier, because core memory meant
> that every single memory access could be considered "durable storage",
> so there was no real need for "fsync(2)" or "msync(2)".
>

This may have been true of the very first Multics machines, but it appears
they switched to solid state memory sometime in the 70s (it's not clear to
me when the SCUs attached to the 6180 switched from core to DRAM:
https://gunkies.org/wiki/Honeywell_6000_series). By the time the DPS8/M
rolled out we must assume they had DRAM. Apparently a cache hierarchy was
added eventually.

        - Dan C.

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

  reply	other threads:[~2022-04-09 13:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 16:32 Dan Cross
2022-04-08  5:30 ` Lars Brinkhoff
2022-04-08 13:34   ` Clem Cole
2022-04-08 14:14     ` Dan Cross
2022-04-08 13:59   ` Dan Cross
2022-04-08 15:28     ` Larry McVoy
2022-04-08 15:35       ` Dan Cross
2022-04-08 19:36       ` Rich Morin
2022-04-08 21:02       ` Greg A. Woods
2022-04-08 23:34         ` Andrew Warkentin
2022-04-09 19:28           ` Greg A. Woods
2022-04-09  3:33         ` Adam Thornton
2022-04-09 12:10         ` tytso
2022-04-09 13:09           ` Dan Cross [this message]
2022-04-09 19:14           ` Greg A. Woods
2022-04-08 15:45     ` Jon Steinhart
2022-04-08 16:07 Noel Chiappa
2022-04-10 17:14 Noel Chiappa
2022-04-10 17:31 ` Larry McVoy
2022-04-10 20:41 ` John Cowan

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='CAEoi9W4Y1R28mg4uFy_=4H1h_ufcwrgSi0Yn9YxjorwQ6JehKw@mail.gmail.com' \
    --to=crossd@gmail.com \
    --cc=tuhs@minnie.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).