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 dholl...@netbsd.org