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@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
