Re: nfsd: Use vfs_fsync_range() in nfsd_commit

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

 



On Fri, 29 Jan 2010 18:58:52 -0500
"Dr. J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:

> On Fri, Jan 29, 2010 at 04:39:11PM -0500, Trond Myklebust wrote:
> > On Fri, 2010-01-29 at 16:27 -0500, Christoph Hellwig wrote: 
> > > And not actually touched by your patch, but that is the reason to
> > > open/close the file if we don't actually do anything with it for an
> > > async export?
> > 
> > I must admit that I was wondering about that too. I'm assuming that the
> > reason is to provide consistent behaviour w.r.t. access checks and
> > possibly also to ensure that NFSv4 delegations are revoked. Perhaps
> > Bruce could comment?
> 
> Do delegations need to be revoked on commit?  (And do we care about
> access checks?)
> 
> We could do both without the need for an actual open, but I don't know
> that it matters much either way.
> 

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.

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux