Re: nfsd: Use vfs_fsync_range() in nfsd_commit

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Wed, 2010-03-17 at 15:08 -0400, Jeff Layton wrote: 
> Is there any reason that we need to revoke the delegation on a commit?
> 
> The only real effect is that writes would be flushed to stable storage.
> The VM on the server could just decide the flush the data to stable
> storage whenever it feels like it without revoking the lease. I don't
> see why we'd need to revoke the lease just because a client asked for
> the flush.
> 
> Bruce has already chimed in on it, but a deadlock of sorts has popped
> up relating to this:
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=551028#c10
> 
> ...and it seems like not recalling the delegation on a COMMIT might
> help resolve it.

I agree. A commit doesn't change the inode in any way, so it shouldn't
require you to revoke the delegation.

Furthermore, I think that the write access check there is incorrect too.
The posix definition of fsync() doesn't specify that the file descriptor
has be writeable, and since COMMIT semantics are supposed to be modelled
on fsync...

Cheers
   Trond