The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
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>
Subject: [TUHS] Re: 'Huge' file support removed from PWB1
Date: Thu, 09 Mar 2023 15:07:17 +0000	[thread overview]
Message-ID: <em202e3a6e-e454-4506-ae4d-35f66403b278@ad99ed46.com> (raw)
In-Reply-To: <CAMQbRb3ObGJ_ASJKDpDsdXbr0xrSD9knN-1mXZhsU-gStyQ3ZQ@mail.gmail.com>

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

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: 2497 bytes --]

  parent reply	other threads:[~2023-03-09 15:07 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 [this message]
2023-03-09 15:13     ` Ron Natalie
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=em202e3a6e-e454-4506-ae4d-35f66403b278@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).