nfs_file_fsync now calls nfs_commit_node(), which calls nfs_scan_commit(), which can return positive value of number of pages committed. If that number is > 0, then value is propagated back from fsync to vfs_fsync to nfs_file_flush to sys_close to caller, making applications very unhappy: 15497 close(1) = 2 15497 munmap(0x7fdcaede6000, 32768) = 0 15497 write(2, "diff: ", 6) = 6 15497 write(2, "standard output", 15) = 15 15497 write(2, "\n", 1) = 1 15497 exit_group(2) = ? 15516 close(1) = 1 15516 munmap(0x7f454d92b000, 32768) = 0 15516 write(2, "diff: ", 6) = 6 15516 write(2, "standard output", 15) = 15 15516 write(2, "\n", 1) = 1 15516 exit_group(2) = ? 15535 close(1) = 1 15535 munmap(0x7f8ec09fd000, 32768) = 0 15535 write(2, "diff: ", 6) = 6 15535 write(2, "standard output", 15) = 15 15535 write(2, "\n", 1) = 1 15655 close(1) = 1 15655 munmap(0x7f9528391000, 32768) = 0 15655 write(2, "grep: ", 6) = 6 15655 write(2, "write error", 11) = 11 As far as I can tell, this is a culprit: commit af7fa16506bf9b6323e862a61e14c20555152bb3 Author: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Sat Jul 31 14:29:06 2010 -0400 NFS: Fix up the fsync code Christoph points out that the VFS will always flush out data before calling nfs_fsync(), so we can dispense with a full call to nfs_wb_all(), and replace that with a simpler call to nfs_commit_inode(). Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Fix seems to be to either switch to NFSv2 :-( or modify nfs_file_fsync to turn positive values returned by nfs_commit_inode to zeroes. Thanks, Petr
Should be fixed by commit 0702099bd86c33c2dcdbd3963433a61f3f503901 (NFS: fix the return value of nfs_file_fsync())
Please reopen if this is not the case