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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
