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(a)ronnatalie.com>
To "Kenneth Goodwin" <kennethgoodwin56(a)gmail.com>; "Noel
Chiappa"
<jnc(a)mercury.lcs.mit.edu>
Cc "The Eunuchs Hysterical Society" <tuhs(a)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