David Holland <dholland-t...@netbsd.org> 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 m...@netbsd.org
