Vijay Bellur <vbellur@xxxxxxxxxx> wrote: > 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. I modified by FUSE implementation to send FATTR_SIZE|FATTR_FH in one request, and FATTR_MODE|FATTR_FH|FATTR_MTIME|FATTR_ATIME in a separate one, and the test passes fine. On your test not raising the bug: Is it possible that Linux already sent a FATTR_SIZE|FATTR_FH when fchmod() is invoked, and that glusterfs discards a FATTR_SIZE that does not really resize? Did you try with supplying a bigger size? > > 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. Right, this was an unfortunate copy/paste. However reverting to correct code does not fix the bug when FUSE sends FATTR_SIZE is set with FATTR_MODE at the same time. > I am not sure why fchmod() should set size. Csaba, any thoughts on this? This is an optimization. You have an open file, you just grew it and you change mode. The NetBSD kernel and its FUSE implementation do the two operations in a single FUSE request, because they are smart :-) I will commit the fix in NetBSD FUSE. But one day the Linux kernel could decide to use the same shortcut too. It may be wise to fix glusterfs so that it does not assume FATTR_SIZE is not sent with other metadata changes. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx
