On Thu, 2012-09-13 at 13:57 -0400, J. Bruce Fields wrote:
> On Wed, Sep 12, 2012 at 04:14:38PM +0000, Adamson, Andy wrote:
> >
> > On Sep 12, 2012, at 11:21 AM, Myklebust, Trond wrote:
> >
> > > On Wed, 2012-09-12 at 15:13 +0000, Adamson, Andy wrote:
> > >> After doing more test verification, here are the reasons for the low watermark. Reason #2 is the strongest justification.
>
> 1 and 2 don't sound right. What exactly were the test failures?
>
> The client and server's gss code already check the context expiry for
> us--we don't want an extra check in an upper layer on the client.
>
> The context *will* expire unexpectedly sometimes, and we do have to
> handle that. (The server's clock could be a tad faster than the
> server's, or the server could reboot, etc., etc.)
>
> I agree with all the suggestions for trying to anticipate expiry in the
> normal cases and preparing to minimize the damage, that's fine. But
> once the expiry finally comes we should leave the existing mechanisms to
> do their job.
Right, but the problem that the existing mechanisms have is that due to
asynchronous reads and writes, the application can end up eating
sizeable chunks of memory. It can also end up grabbing locks without
being able to free them afterwards.
SP4_MACH_CRED solves most of these issues, but NFSv4.1 is less pervasive
than NFSv4 at this point, so it would be nice to have a solution for the
latter too.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
