Hard links vs. Soft links

[Jeff Beadles]

anagram at desire.wright.edu ((For Mongo)) writes:
>What is the difference between a hard link and a soft link?  Besides the fact
>that a hard link seems to make a copy of the file, while the soft link just
>points the OS to the real file.  In broader terms, my question is this: I have
>a Tektronix 4301 that has the commands ls, ll, lf, lg, and lx, all of which are
>derivatives or ls.  They are all the same size, and they are all linked
>together.  When I had a system error and all the links were destroyes, I
>deleted them all, except ls, and re-linked them using soft links.  I saved
>about a quarter of a meg of disk-space.  I have come across some other files
>that are the same way, and am wondering how much space I can save, compared to
>how much system performance I will lose.  Can anyone tell me how soft links vs.
>hard links will affect system performance. 
>
>Thanks,
>Steve P Potter
>Systems Manager
>Mission Research Corp


First, under UTek (a 4.2BSD based Unix), the l{f,g,l,r,s,x} commands are all
linked to the same binary.  The binary then looks at argv[0] to determine what
flags should be set by default.  Here's a 'll -i' of the files in question:

 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/lf
 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/lg
 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/ll
 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/lr
 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/ls
 8166 -r-xr-xr-x  6 sys         54272 Apr 12  1989 /bin/lx

Note, that they all have the same inode number.  Thus, if you did a 'df' in a
quiescent file system, then removed all but one of the 'l*' commands, and did
another 'df', the space used would not change at all.

Symbolic links are slower to follow.  This is because the kernel has to first
get the symbolic link, resolve it to find what it points to, and then resolve
the file that it points to.

By using a hard link, the kernel can immediately resolve it to inode '8166' and
do the right thing.

I just did a little test to see how much this effects things.  I stat(2)'ed a
file 50,000 times.  The first time was stat'ing a plain file, and the second
was a symbolic link that pointed to a file in the same directory.  It was the
same file, so everything should even be cached...

Here's the results:

type		Time(clock)
-----------	----------
plain file:	45.5 seconds
Symbolic link:	94   seconds

This is not a though test procedure, but the results are about what I expected.
FYI, here's test program that I used:

-------------------snip here------------
#include <sys/types.h>
#include <stat.h>

main()
{
	register long count;
	struct stat statbuf;


	count = 0L;

	while ( count++ < 50000L)
		(void)stat("/tmp/stat", &statbuf);
}
-------------------snip here------------

After compiling, I did the following:

% rm /tmp/stat
% touch /tmp/stat
% time stest 
0.1u 45.5s 0:45 99% 0+0k 0+1io 1pf+0w
% rm /tmp/stat
% touch /tmp/foo
% ln -s /tmp/foo /tmp/stat
% time stest
0.1u 93.8s 1:34 99% 0+0k 0+1io 1pf+0w

Overall, if you traverse the links often, then you will see a performance hit.
Symbolic links do have their advantages.  They will span filesystems.

	-Jeff
-- 
Jeff Beadles				jeff at quark.WV.TEK.COM 
Utek Engineering, Tektronix Inc.
			SPEEA - Just say no.