Messages in this thread | | | Date | Sun, 27 Jun 1999 23:47:31 -0400 (EDT) | From | Alexander Viro <> | Subject | re: generalizing A. Viro's killfile |
| |
On Sun, 27 Jun 1999, Rick Hohensee wrote:
> Alexander, could you stick me in your killfile too? Thanks :o) Huh? Oh, well... Scheduled for inclusion ;-)
> What do Real Users(tm) use hardlinks for? I may soon tweak my ln > so that -s is the default.
cp -rl clean_tree build_tree cd build_tree make >/tmp/1 2>/tmp/2 & tail -f /tmp/2 [oops, the sucker blew up] [looking at the output] vi foo/bar.c [etc] (cd .. ; diff -urN base_tree clean_tree >current_patch) & make >/tmp/1 2>/tmp/2 & [...]
It's a SOP here. Just one of the examples. Changing defaults in ln will break quite a few scripts, BTW. What for? Moreover, strictly speaking everyone is using hardlinks. The difference is in the number of links pointing to file. Symlinks and hardlinks are different and have different uses. Many of them. Tossing one sort just because you don't know what it is for... Well, your business, indeed. Since you don't care for breaking the existing stuff anyway - why not? Not in the kernels that run on my boxen, though, but it's kinda obvious. I doubt that patch killing hardlinks has any chance to make its way into the Linus' tree, but only one person can tell for sure ;-)
As for the "..." - name doesn't make a file nonexistent. Making stat() read it is *not* a good idea, for example because you may have insufficient permissions on a directory. Moreover, it will make performance *suck* - just think of the amount of accesses. Right now stat() is extremely cheap - in the worst case it's one access to inode. You are going to turn it into: access to inode + access to directory + access to inode of "..." + access to the data in "...". 4 times. Do it and measure compare ls -l times. Or make, for that matter. What for? To make ls tell the sizes of all files referenced from subdirectories? Not to mention the fact that it will prohibit changing anything on /usr/local if /usr is mounted r/o. Moreover, for NFS-exported stuff you are in big trouble - different clients may have different stuff mounted atop of it. s/NFS/any other network filesystem/. If you are limiting the propagation on the filesystem boundary - there goes the "intuitive" stuff.
Look - you want to have extremely expensive information. It changes on every write(), truncate(), etc. You can pay the cost upon explicit request (du) and you can make every operation pay, so that equivalent of du was faster. That is, make innocent pay for guilty. And let's not go into the amount of races you will get that way - any operation that changes many places is the royal PITA. Just look into fs/umsdos to get a feeling of the thing. It has to use extremely crude locking and it doesn't help the performance, to say the least. And you will have performance problems aside of locking.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |