gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] NULL loc in posix_acl_truncate


From: Vijay Bellur
Subject: Re: [Gluster-devel] NULL loc in posix_acl_truncate
Date: Sun, 27 May 2012 12:24:43 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 05/27/2012 10:47 AM, Emmanuel Dreyfus wrote:
Emmanuel Dreyfus<address@hidden>  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]