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