On 05/27/2012 10:47 AM, Emmanuel Dreyfus wrote:
Emmanuel Dreyfus<manu@xxxxxxxxxx> wrote:
In frame 10, loc->path and loc->inode are NULL.
As I understand this is a FUSE implentation problem. fchmod() produces a
FUSE SETATTR. If the file is being written, NetBSD FUSE will set mode,
size, atime, mtime, and fh in this operation. I suspect Linux FUSE only
sets mode and fh and this is why the bug does not appear on Linux: the
truncate code path is probably not involved.
For the testcase that you sent out, I see fsi->valid being set to 1
which indicates only mode on Linux. The truncate path does not get
involved. I modified the testcase to send ftruncate/truncate and it
completed successfully.
Can someone confirm? If this is the case, it suggests the code path may
have never been tested. I suspect there are bugs there, for instance, in
pl_truncate_cbk, local is erased after being retreived, which does not
look right:
local = frame->local;
local = mem_get0 (this->local_pool);
I don't see this in pl_truncate_cbk(). mem_get0 is done only in
pl_truncate(). A code inspection in pl_(f)truncate did not raise any
suspicions to me.
About fchmod() setting size: is it a reasonable behavior? FUSE does not
specify what must happens, so if glusterfs rely on the Linux kernel not
doing it may be begging for future bugs if that behavior change.
I am not sure why fchmod() should set size. Csaba, any thoughts on this?
Vijay
