gnb@mullian.OZ (Greg Bond) (08/12/85)
In article <9789@ucbvax.ARPA> kre@ucbvax.ARPA (Robert Elz) writes: (Speaking of symbolic links...) >Almost. The owner is used to account for the space (1 block) >used by the symbolic link in disc quota calculations. You >can chown() symbolic links to alter who is charged this way. > >Robert Elz ucbvax!kre kre@monet.berkeley.edu 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? Yes, I know it probably isn't worth the complexity, but I'd be interested what proportion af filesystems are taken by files less than 40 bytes. On our system this these have a utilisation of ~ (40/2000) = 2%!! Cheerio, Greg. -- Programmers Dictionary: ``argc'' - Expression of frustration. See argv. In-Real-Life: Gregory Bond (gnb@mullian), Electrical Engineering, Melbourne Uni UUCP: ...!seismo!munnari!mullian.oz!gnb CSNET: gnb@mullian.oz ARPA: munnari!mullian.oz!gnb@SEISMO.ARPA ACSNET: gnb@mullian.oz (Domains!)
rees@apollo.uucp (Jim Rees) (08/22/85)
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.
On the Apollo system, we store the link text in the directory itself,
saving even the cost of allocating an inode. This also means the link text
can be as long as you want, not limited by the size of the block pointers.
We also have 4.2 style symbolic links for anyone who wants to use them,
but given the vacuous semantics of ownership and mode, few people choose to.