On Friday 23 October 2015 07:28 AM, Marty Rosenberg wrote:
First off: I've based my work off of the release of 3.7.3, since it was
the most recent release when I started this project, and I couldn't get
HEAD to build on freebsd. (I'm using a freebsd server, and linux clients)
I realize that many things will be broken by doing this (renaming open
files, deleting open files, possibly some other stuff), but I can live
with those limitations.
What I've done:
I've modified the code to failback to a symlink if making a hardlink
fails (which it will do somewhat frequently due to being on a different
filesystem).
I created an extended property on symlinks that are emulating hard links
changed the setattr code to check this before it tries to set the
attributs, and if it is set, it dereferences the link, then proceeds
with the setattr
To test this, I made a file, and ran chmod +x on it
the good: attributes were correctly set on the file!
the bad: chmod says it failed with EIO
my issue: I have no clue where this EIO is coming from. Under the
hood,s chmod is calling fchmodat
After no luck with printf debugging, I just ran gluster under gdb, and
set a breakpoint on send_fuse_iov. Here's the backtrace:
#0 send_fuse_iov (this=0x63a150, finh=0x7fffe0005fe0,
iov_out=0x7ffff08e7500, count=2) at fuse-bridge.c:158
#1 0x00007ffff550fcfd in send_fuse_data (this=0x63a150,
finh=0x7fffe0005fe0, data=0x7ffff08e75a0, size=104) at fuse-bridge.c:197
#2 0x00007ffff5511be1 in fuse_attr_cbk (frame=0x7fffe000145c,
cookie=0x7fffe000616c, this=0x63a150, op_ret=0, op_errno=117,
buf=0x7fffe0006734, xdata=0x0) at fuse-bridge.c:734
Can you break at fuse_setattr_cbk() and check the backtrace? That could
provide more relevant information for the chmod failure.
Regards,
Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
