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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13598 invoked from network); 9 Apr 2022 13:11:27 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2022 13:11:27 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0DCEC9D70E; Sat, 9 Apr 2022 23:11:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 428639D680; Sat, 9 Apr 2022 23:09:30 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="R2qBq2oS"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DF0219D680; Sat, 9 Apr 2022 23:09:25 +1000 (AEST) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by minnie.tuhs.org (Postfix) with ESMTPS id EF3E19D665 for ; Sat, 9 Apr 2022 23:09:22 +1000 (AEST) Received: by mail-ot1-f41.google.com with SMTP id e25-20020a0568301e5900b005b236d5d74fso8051715otj.0 for ; Sat, 09 Apr 2022 06:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DK/YE8yM1ueblxKVsBlNXkBa6FKFOeSXOnA4h54blnQ=; b=R2qBq2oS3/uVCiFo2JeTSH2sBf8A/WUsdlSndwr2DqUsNQZS2ZN5FGixwBlij+Ao2A vYD9CJv1qaQHeAzJubZf6eov3/v3Ah9NV2uG7z64cV0JMMZQWJSF2KiGOcZvaX8BZV8T yX46zMme8N1AXVsMaiXCTPnY6sVSrwyJPrJZ49XL8ifgE/lJqxqO7WgUFVzOeneoEYlZ iLYUv3TUQaK4g/Q3j4aF13QEOvHdf9/QO1Yt91l5/az8wPEziSSkFkRqL5V+dLsRbE5i sw//YsD+Vly+lWEKYVMbiNHLrtKEmrlAT2ZkYLnB9kUJQSnMwbmPcYatWc3hznmA5Dka nSlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DK/YE8yM1ueblxKVsBlNXkBa6FKFOeSXOnA4h54blnQ=; b=KvaSbETNzkCKmWhXktbQzCdSPLepgSbW1IiasX/fE4jZknutmVvnd+fAZOz7mR+iSO j/xlyqGsZUasSc4F6Szf+eadTDDPLOaC6WQqjtSpl8yk961MS8L077o5ccth2fwfzr8A MQRHLx4/PjvhI8Bojp2vpEsLQ2B9unJmYqfm0PooQ56h654S4P7wb4eQCF7FC6qFmMzE sj63R0OVEq5Lvky1872Raz2/bGqwZNieE1NdkO7Sb7JWgVqIBAI0+dHFsMqeQ7apB4Gd SYc+l1LAgdg7bnYYkXZ0I3Yo3o+BqQMGstCGCDv1iNz/7ro4qH22j/FUGfWDIHxyIE69 Ca6Q== X-Gm-Message-State: AOAM533Kx8UNZq1Y+ptgvpt3WiIqwCJZ0bP04Ap4sAGqUlBDwH3UbtGC p83a/hMcubvyGud+3PMo2+5dZB684N865DREdF5qtsvM X-Google-Smtp-Source: ABdhPJyE9tkiXIoNtzuMVAJ33Afdfkeq7wtQKEAZQsbYT9c248/dGY2XJFTh9OKN3Kk2z3hLtVhTOCJ9Hmt2P2sUtFs= X-Received: by 2002:a9d:135:0:b0:5cd:9d22:e9c4 with SMTP id 50-20020a9d0135000000b005cd9d22e9c4mr8259249otu.17.1649509761602; Sat, 09 Apr 2022 06:09:21 -0700 (PDT) MIME-Version: 1.0 References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> In-Reply-To: From: Dan Cross Date: Sat, 9 Apr 2022 09:09:10 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="00000000000064d93805dc386ba5" Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000064d93805dc386ba5 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 9, 2022, 8:18 AM tytso 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. --00000000000064d93805dc386ba5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 b= y
> attaching a "file" to a segment.=C2=A0 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 semanti= cs
> 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&q= uot;,
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/w= iki/Honeywell_6000_series). By the time the DPS8/M rolled out we must a= ssume they had DRAM. Apparently a cache hierarchy was added eventually.

=C2=A0 =C2=A0 =C2=A0 =C2=A0= - Dan C.

--00000000000064d93805dc386ba5--