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, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27620 invoked from network); 25 Jun 2020 00:46:37 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2020 00:46:37 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2CC09945AF; Thu, 25 Jun 2020 10:46:32 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4FDF49459A; Thu, 25 Jun 2020 10:45:53 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="qdn/hZSZ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id EEC519459A; Thu, 25 Jun 2020 10:45:50 +1000 (AEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 82D8E94599 for ; Thu, 25 Jun 2020 10:45:50 +1000 (AEST) Received: by mail-pj1-f51.google.com with SMTP id ev7so1598531pjb.2 for ; Wed, 24 Jun 2020 17:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Y71qpO3P16QK61Ax2zDrQGzyBFEFpGuUy6iSqB0jlTk=; b=qdn/hZSZp0cFB0XEwXO+TM25Ycy87vNvMICxqb+HMU4o6g13xWp6IQGv9LBHzIP+zd sZOVuEE7ifqDsg0IjqlTAIxA39j7HA63hRqj0Lt6yK7wMJxAHeDfLRGVEA3HTBTfTO3U 1B9WLSY1TnD9Mf7D1KPRl6AvFckP1vVH+FRxAVT+0paUvr36zzE47YsHTx/f6m2vQTwF 6PdPzbgdB9lMLFE/j/k/KxFnVqALZomZhZsxiCUZ7cDlhZDLmEdYdy0/zehpJ1kTVMth DqKVu17mlwyq6d0xs9i6QZtXLhwKMUBc6sMZuOmr/EEnvM+JB/OQnDZFgo82Ejah8OFB /YKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Y71qpO3P16QK61Ax2zDrQGzyBFEFpGuUy6iSqB0jlTk=; b=WMtRzmzPT3NphKIK1Gqr6f2PkXTgcEyD2ZXHz84HPG6s5cWoAUOjkYAtqW78sS2hYn 4jaMdLM1pijoTFLoK3yeWDHdU6zsUr7cP6TAQHQfwux8zfl85Kq0DAnlgbcWmIJvw1fq aO9x/rXTIycqO+IqBSncEqURzvxGR3z2iH0rlgXG+WumRHApLrqjYMiQePH+PYFe5lCA xr1E+TKHpKanrEY+Cw1v5P1/mPyqU4gEJA8Zj2lp5c0mty3YhBdkGEy48HoeBRkXGmhF kQwwM1kmYJtLe9GY3d0BvXL4A+O5Mq9IPwSt90N3rUUINDp8TAioBuK6Sb9M4sJ4M9CO UbqQ== X-Gm-Message-State: AOAM530h15x/F0IeoN/yjRc74r3SpsD2OSV4+bw2gMarZaXYZtrS5vTZ a50fmMTNYx3cDlYD6zVp4Jp+zK69EUHGgQmAcmN6wG1U X-Google-Smtp-Source: ABdhPJxFgMrup5oY2sVIW6iOqM4m/LB3C0eeAjQzgZf4KA5TevQFju+vNP04jcfkMXY6sNmZpTCbc9h4Cc6NekZW7pU= X-Received: by 2002:a17:90a:d086:: with SMTP id k6mr419269pju.133.1593045949517; Wed, 24 Jun 2020 17:45:49 -0700 (PDT) MIME-Version: 1.0 References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> In-Reply-To: From: Adam Thornton Date: Wed, 24 Jun 2020 17:45:38 -0700 Message-ID: To: The Unix Heritage Society mailing list Content-Type: multipart/alternative; boundary="000000000000ee94c705a8dde94b" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ee94c705a8dde94b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 2:34 PM Greg A. Woods wrote: > > As far as I can remember Multics didn't really have the concept of a > "mount point". All storage was single-level, i.e. segments (equivalent > in some respects to inodes, but they are also actually the value of the > segment register in the virtual memory hardware), and so files were > either physically in memory or paged out on physical disk devices or > similar, or even out on tape. Where they actually resided was entirely > and permanently hidden from the user. What was called the "filesystem" > was a form of database representing a hierarchical namespace which > pointed at all the known segments (files) regardless of where they were > actually stored. > > Coming to it from a Unix perspective, it's like all storage (core, disk, tape) is mmap()ed. The segment-name database then is just an index relating symbolic names to particular memory locations. It all feels very upside-down to me, but that's probably because I grew up in Unix and never actually used a Multics system until I emulated one with dps8m. Adam --000000000000ee94c705a8dde94b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 24, 2020 at 2:34 PM Greg = A. Woods <woods@robohack.ca>= wrote:

As far as I can remember Multics didn't really have the concept of a "mount point".=C2=A0 All storage was single-level, i.e. segments = (equivalent
in some respects to inodes, but they are also actually the value of the
segment register in the virtual memory hardware), and so files were
either physically in memory or paged out on physical disk devices or
similar, or even out on tape.=C2=A0 Where they actually resided was entirel= y
and permanently hidden from the user.=C2=A0 What was called the "files= ystem"
was a form of database representing a hierarchical namespace which
pointed at all the known segments (files) regardless of where they were
actually stored.


Coming to it from a Unix perspective, = it's like all storage (core, disk, tape) is mmap()ed.

The segment-name database then is just an index relating symbolic n= ames to particular memory locations.

It all feels = very upside-down to me, but that's probably because I grew up in Unix a= nd never actually used a Multics system until I emulated one with dps8m.

Adam
--000000000000ee94c705a8dde94b--