lkml.org 
[lkml]   [1999]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectre: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.086 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site