jerry@oliveb.UUCP (Jerry Aguirre) (08/14/85)
> 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@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
ed@mtxinu.UUCP (Ed Gould) (08/19/85)
In article <567@oliveb.UUCP> jerry@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@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."
bees@infoswx.UUCP (08/23/85)
In reference to the discussion of "inode files": Amdahl's UTS filesystem stores small files in the inode. Since the inode is quite large under UTS, quite a number of files never need data blocks. This is good, since data blocks are 4k. If I remember correctly, there is an odd number of bytes around 1200 that can be stored in the inode. Ray Davis Teknekron Infoswitch, Richardson infoswx!bees, (214)644-0570