Space for small files

[Ed Gould]

In article <567 at oliveb.UUCP> jerry at oliveb.UUCP (Jerry Aguirre) writes:
>> It seems a waste to allocate a whole fragment/block (2k on our system)
>> when most symbolic links are about 20 bytes long ...
>> 
>> In-Real-Life: Gregory Bond (gnb at mullian)
>
>Unix used to do this.  The first N (say 40) bytes of a file were kept in
>the inode.  The idea was that there were lots of small files such as dot
>files and one line shell scripts that could be accessed without the
>extra seek and read.

I don't remember Unix keeping any data in the inode.  In the Sixth Edition,
there were two types of files, "large" and "small", where the pointers in
small files were direct pointers, ala the first 10 in Seventh Edition files,
and were indirect in large files.

>This was eliminated because it messed up the buffering.  Instead of a
>block corresponding to every 512 bytes, the first N bytes went into the
>inode and the following blocks were offset by N bytes.  You either had
>to add complexity to the buffered IO packages or eat the overhead of
>unaligned writes.
>
>HOWEVER!  If files less than N were stored in the inode and files
>greater than N were stored only in the data blocks this would eliminate
>the alignment problem.  When a file grew beyond the N size you would
>copy the data from the inode into the data block.  The copy is some
>overhead but compared to the 4.2BSD block/fragment code it is trivial.
>
>You don't even have to wast space in the inode or add a flag.  The data
>could be stored in the space normally used for the disk addresses and
>the size of the file would determine whether to treat that area as data
>or disk addresses.

The change in format from 6th to 7th Editions had nothing to do with buffer
alignment (there wasn't any change) or with efficiency.  Consider what had to
happen when a file grew past the limit of "small":  The block pointers in
the inode had to be copied into a filesystem block, and the inode modified
to point to that block.  This led to many inconsistent filesystems, because
the 6th Edition system wasn't nearly as stable as we're used to today, and
a crash after the inode had been modified and written to disk, but before
the block with the pointers was written, yielded a garbage file, and a
corrupted filesystem.

So, anyone who has designs on implementing such a scheme where some data
is kept in the inode, *please* be sure it's done with correctly-ordered
disk writes!

-- 
Ed Gould                    mt Xinu, 2910 Seventh St., Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"A man of quality is not threatened by a woman of equality."