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!)