Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site mullian.OZ Path: utzoo!linus!philabs!cmcl2!seismo!munnari!murdu!mullian!gnb From: gnb@mullian.OZ (Greg Bond) Newsgroups: net.bugs.4bsd Subject: A thought on symbolic links ( was utime(2) ) Message-ID: <57@mullian.OZ> Date: Sun, 11-Aug-85 20:20:31 EDT Article-I.D.: mullian.57 Posted: Sun Aug 11 20:20:31 1985 Date-Received: Tue, 13-Aug-85 03:44:50 EDT References: <9789@ucbvax.ARPA> Reply-To: gnb@mullian.OZ (Greg Bond) Distribution: net Organization: Elec Eng, Melbourne Uni, Australia Lines: 30 Summary: Why allocate whole blocks to symbolic links?? 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!)