Re: Adding linux_link(2) system call, second round

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

On Mon, Aug 01, 2011 at 04:05:32AM +0200, Emmanuel Dreyfus wrote:
 > > You still haven't explained what glusterfs is doing that's so evil or
 > > why it can't be fixed by having it copy the symlink when that's the
 > > case in question.
 > 
 > glusterfs uses the native filesystem as its storage backend. When you
 > rename a filesytem object in the distributed and replicated setup, they
 > have to make sure it remains accessible by another client during the
 > operation. 
 > 
 > Directories are all present on all servers and therefore are just
 > treated by a rename(2). Other objects are stored on some server and are
 > reteived using a DHT. When they are renamed, they are treated by a
 > distributed link(2)/rename(2)/unlink(2) algorithm. This breaks on NetBSD
 > when the object is a symlink to a directory or a symlink to a
 > nonexistent target, since you cannot link(2) to such an object. 

Sure. But what does it actually do, such that if you have a symlink it
doesn't work to copy the symlink instead of hardlink it?

 > The fix is not traightforward, and require a change in the way glusterfs
 > stores symlinks in its distributed and replicated setup.

Why?

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