From: Peter Staubach <staubach@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
NFS List <nfs@lists.sourceforge.net>
Subject: Re: [PATCH] 64 bit ino support for NFS server
Date: Wed, 08 Aug 2007 16:49:00 -0400 [thread overview]
Message-ID: <46BA2C3C.6040504@redhat.com> (raw)
In-Reply-To: <20070808203555.GL16171@fieldses.org>
J. Bruce Fields wrote:
> 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.
>
>
Yes.
>> 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?
>
>
The support in fill_post_wcc() doesn't invoke lease_get_mtime().
Thanx...
ps
>> 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
next prev parent reply other threads:[~2007-08-08 20:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-03 19:11 [PATCH] 64 bit ino support for NFS server Peter Staubach
2007-08-03 19:29 ` Peter Staubach
2007-08-04 22:32 ` J. Bruce Fields
2007-08-06 15:40 ` Peter Staubach
2007-08-06 16:09 ` J. Bruce Fields
2007-08-08 20:07 ` Peter Staubach
2007-08-08 20:35 ` J. Bruce Fields
2007-08-08 20:49 ` Peter Staubach [this message]
2007-08-08 21:01 ` J. Bruce Fields
2007-08-16 16:10 ` Peter Staubach
2007-08-17 16:51 ` J. Bruce Fields
2007-08-17 18:30 ` Peter Staubach
2007-08-17 18:36 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BA2C3C.6040504@redhat.com \
--to=staubach@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.