[Gluster-devel] dht and rename: how is it supposed to work?
Emmanuel Dreyfus
manu at netbsd.org
Fri Jul 29 08:09:01 UTC 2011
On Fri, Jul 29, 2011 at 11:03:34AM +0530, Amar Tumballi wrote:
> rename(2) can be performed on a symlink too. Hence, I guess what distribute
> is doing is valid here.
The problem is not rename(2) here, but link(2) that dht produces for a
rename(2). By the way I spoted the difference between Linux and NetBSD
that causes the bug: link(2) will fail on a symlink to a directory on
NetBSD, while it works on Linux
$ cd /tmp
$ mkdir i386
$ ln -s i386 inst.xxx
$ ln inst.xxx machine
ln: machine: Operation not permitted
$ uname
NetBSD
$ mkdir i386
$ ln -s i386 inst.xxx
$ ln inst.xxx machine
$ ls -ld machine
lrwxrwxrwx 2 manu manu 4 jui 29 10:03 machine -> i386
$ uname
Linux
I still have to investigate whether NetBSD behavior is compliant with SUSv2.
Would it make sense for glusterfs dht to use rename(2) on IA_IFLNK just
like it does for IA_IFDIR? I mean a change like this:
--- xlators/cluster/dht/src/dht-rename.c.orig
+++ xlators/cluster/dht/src/dht-rename.c
@@ -763,9 +763,10 @@
oldloc->path, src_hashed->name, src_cached->name,
newloc->path, dst_hashed->name,
dst_cached ? dst_cached->name : "<nul>");
- if (IA_ISDIR (oldloc->inode->ia_type)) {
+ if (IA_ISDIR (oldloc->inode->ia_type) ||
+ IA_ISLNK (oldloc->inode->ia_type)) {
dht_rename_dir (frame, this);
} else {
local->op_ret = 0;
dht_rename_create_links (frame);
--
Emmanuel Dreyfus
manu at netbsd.org
More information about the Gluster-devel
mailing list