From: "Ron Natalie" <ron@ronnatalie.com>
To: "Ron Natalie" <ron@ronnatalie.com>,
"Kenneth Goodwin" <kennethgoodwin56@gmail.com>,
"Noel Chiappa" <jnc@mercury.lcs.mit.edu>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: 'Huge' file support removed from PWB1
Date: Thu, 09 Mar 2023 15:13:07 +0000 [thread overview]
Message-ID: <em8b72af4c-af4c-4444-a00f-4074976df225@ad99ed46.com> (raw)
In-Reply-To: <em202e3a6e-e454-4506-ae4d-35f66403b278@ad99ed46.com>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
That should read eight blocks in the inode not four in the first
sentence (and up to eight later).
------ Original Message ------
From "Ron Natalie" <ron@ronnatalie.com>
To "Kenneth Goodwin" <kennethgoodwin56@gmail.com>; "Noel Chiappa"
<jnc@mercury.lcs.mit.edu>
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 3/9/2023 10:07:17 AM
Subject [TUHS] Re: 'Huge' file support removed from PWB1
>In the version 6 file system, If the file was less than 4K, the four
>blocks in the inode refer directly to the disk blocks containing the
>file data.
>After thef ile grows past that, the large bit is set in the inode and
>these blocks contain the single indirect blocks, referencing 256 data
>blocks each, until you used up seven of these.
>The last one was the double indirect block that pointed to other
>indirect blocks. The file size was stored in 24 bits, and the block
>numbers were 16 bit.
>
>As Noel points out, PWB uses the same file system as V6 but with the
>HUGE (last double indirect) code commented out. I have no idea why and
>I never noticed it before. While we used a lot of stuff from the PWB
>distribution (notably SCCS) we had no real interest in using the PWB’s
>kernel because our V6 kernel had diverged sharply from the Bell
>versions.
>
>Version 7 came around with a different filesystem layout. File sizes
>were 32 bits, and the disk block indexes were 24 bits. The latter was
>stored as a series of bytes on the disk but expanded into longs in
>memeory.
>There was no large bit anymore. The first 8 blocks addresses in the
>inode were always single indirect, the next two were single indirect,
>and the last one was double indirect. (If my memory serves me right)
>
>At BRL, we modified our very-hacked V6 kernel to have the ability to
>mount either V6 or V7 filesystems.
>
>We never ran V5, but I think V5 is essentially the V6 file system
>without the HUGE support again.
>
>-Ron
[-- Attachment #2: Type: text/html, Size: 3853 bytes --]
next prev parent reply other threads:[~2023-03-09 15:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 13:10 [TUHS] " Noel Chiappa
2023-03-09 8:21 ` [TUHS] " Kenneth Goodwin
2023-03-09 12:40 ` Jonathan Gray
2023-03-09 15:07 ` Ron Natalie
2023-03-09 15:13 ` Ron Natalie [this message]
2023-03-09 17:35 ` arnold
2023-03-09 17:01 ` Tom Ivar Helbekkmo via TUHS
2023-03-09 23:25 ` Clem Cole
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=em8b72af4c-af4c-4444-a00f-4074976df225@ad99ed46.com \
--to=ron@ronnatalie.com \
--cc=jnc@mercury.lcs.mit.edu \
--cc=kennethgoodwin56@gmail.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).