Re: Adding linux_link(2) system call (Was: Re: link(2) on a symlink to a directory fails)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jul 29, 2011 at 02:20:10PM +0000, Emmanuel Dreyfus wrote:
 > > All in all it seems like a bug for glusterfs to be using link this way.
 > 
 > Given the context, that will not be easy to fix and would have a performance
 > hit. This is a filesystem distributed using a distributed hash table, and
 > in order to avoid the issue, the client would have to resolve symlinks 
 > on its own, which implies a few transactions back and forth with servers.

Huh? Why? Creating another symlink with the same contents should have
the same effect; it'll use an additional inode, but that should be
harmless.

 > What about adding a linux_link(2) that would do exactly what link(2) does
 > but without the FOLLOW flag to NDINIT on the path argument? If 
 > linux_link(2) seems unreasonable, it could be lazy_link(2), weak_link(2),
 > braindead_link(2) or whatever.

You'll also need to update every filesystem to allow this and update
all the various fsck programs to allow filesystems to be in this
state. I'd disagree with this as it seems like a nonsensical thing to
do.

-- 
David A. Holland
dholland%netbsd.org@localhost