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

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

David Holland <dholland-tech%netbsd.org@localhost> 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. 

The fix is not traightforward, and require a change in the way glusterfs
stores symlinks in its distributed and replicated setup. I suspect it
may involve treating such objects like directories, and have them
duplicated on all servers. An alternative would be to sacrifice the
garantee that symlinks are available during a rename, at least for
NetBSD.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost