Space for small files

[Jerry Aguirre]

> It seems a waste to allocate a whole fragment/block (2k on our system)
> when most symbolic links are about 20 bytes long. A possibility would
> be to set a bit in the inode to indicate the linked-to filename is
> short (< 40 bytes?) & the data is contained the block pointer area of
> the inode. This would allow symbolic links for ``free'', reduce
> wastage, and improve the speed of symbolic links.
> 
> Perhaps this could be extended to short files also?
> 
> In-Real-Life: Gregory Bond (gnb at mullian), Electrical Engineering, Melbourne Uni

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.

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.

				Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry