Xref: utzoo comp.unix.wizards:23588 comp.unix.questions:24949 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca.wv.tek.com!quark!jeff From: jeff@quark.WV.TEK.COM (Jeff Beadles) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: Hard links vs. Soft links Message-ID: <8332@orca.wv.tek.com> Date: 23 Aug 90 17:07:37 GMT References: <1084.26d2a42b@desire.wright.edu> Sender: news@orca.wv.tek.com Reply-To: jeff@quark.WV.TEK.COM (Jeff Beadles) Followup-To: comp.unix.wizards Organization: Tektronix, Inc., Wilsonville, OR Lines: 93 anagram@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 #include 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@quark.WV.TEK.COM Utek Engineering, Tektronix Inc. SPEEA - Just say no.