From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH] 64 bit ino support for NFS server
Date: Wed, 8 Aug 2007 16:35:55 -0400
Message-ID: <20070808203555.GL16171@fieldses.org>
References: <46B37DE6.80706@redhat.com> <46B38206.6050504@redhat.com>
	<20070804223256.GA1155@fieldses.org> <46BA2289.5060902@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Neil Brown <neilb@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	NFS List <nfs@lists.sourceforge.net>
To: Peter Staubach <staubach@redhat.com>
In-Reply-To: <46BA2289.5060902@redhat.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Wed, Aug 08, 2007 at 04:07:37PM -0400, Peter Staubach wrote:
> I'm testing a new version of the patch, which addresses this
> issue, but then I got to wondering, what is lease_get_mtime()
> really for and is it solving a real problem, and if so, is it
> solving it in a reasonable fashion?
>
> It appears to me that it is used to detect when an application
> on the server has acquired an exclusive lease for a file and
> may be modifying it, but without informing the kernel.  If it
> was informing the kernel, then the mtime would be updated.
>
> NFS doesn't support leases like this, so it would need to be
> an application running on the server, either as a standalone
> application or as a server for some other service.

Let's say it's Samba, since that's probably what is is.

So Samba is holding a write lease on the file on behalf of one of its
clients.  We never see an open from our NFSv2/v3 client--if it doesn't
have data cached, we may never even see a read, just access and
getattr--so we don't know to break that lease.

(Actually, if a write lease, like an NFSv4 write delegation, is meant to
cover file attributes as well as data, then perhaps stat should break
write leases.  That sounds painful.)

Anyway, the delay between the time the Samba client makes a change and
the time the NFS client sees it could be unbounded.  Whereas with
lease_get_mtime() the client will invalidate its cache and perform a
read, which *does* break the lease (in nfsd_open).

But I agree that this is a strange compromise, and I'd like to
understand better what the semantics for sharing with a Samba client are
supposed to be.

> And, why does it matter whether the attributes are being
> returned via GETATTR, via a post_op_attr, or via a post_op_attr
> as part of a wcc_data?  The first two cases invoke lease_get_mtime(),
> while the third does not.

What's the code path in the third case?

> Could this not lead to time jumping around on a particular file,
> forwards and backwards?

Yeah, sounds bad.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs