[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Re: [nfsv4] re: byte range delegations
From:       Mike Eisler <email2mre-ietf () yahoo ! com>
Date:       2005-07-19 20:11:36
Message-ID: 20050719201136.93376.qmail () web30307 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

-- Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> lau den 16.07.2005 Klokka 18:10 (-0700) skreiv Mike Eisler:
> 
> > You want us to specify a protocol that has the explicit goal of supporting
> > correct mmap() and page faulting but don't want to us specify consistent rules for
> > how clients and servers achieve it. There is lots of stuff in RFC3530 from Dave Noveck 
> > that codified how clients MUST achieve close-to-open consistency. We (me) whined
> > for a while that this was out of bounds, but in the end we came to our senses.
> > If we want to do cache coherency, we have to codify how to do it.
> 
> I agree that the problem of thrashing is worth discussing. I do not
> agree that considering specifying process scheduling on the client is
> worth discussing.
^^^^^^^^^^^^^^^^^^

It's worth discussing because it is an aspect of thrashing.
"Rough consensus and running code", the traditional "Implementation"
advice in NFS specs, etc.

> > > I don't see how a client can guarantee more than that. Locking too has
> > > the same problem: a page can get ejected by the memory reclaimer for
> > > instance before the process has accessed it. We may be widening the
> > > window for thrashing, but we certainly didn't create it.
> > 
> > If by "Locking" you mean byte range caching without cache coherency,
> > I don't see the problem. If a byte range delegation is recalled,
> > the client can send its byte range locks to the server, and after
> > that use synchronous I/O for the locked ranges. You lose performance, but
> > because you aren't attempting true POSIX semantics, you aren't introducing
> > new problems. This is the same contract NFSv4.0 whole file delegations 
> > provide. (But I've yet to be convinced that cache coherent NFS is NFS).
> 
> You have the same problem. In the case of a low memory situation, the
> kernel threads that handle recovering locks could end up not getting
> scheduled until after the server forcibly revokes the delegation.

Revocation is not recall. Nor is it a new problem.

> I agree this is unlikely, but you appear to be raising this issue as a
> bogeyman in one case, but not the other. What is the central issue here
> that I am missing?

What you are missing is the difference between caching and cache consistency.
NFS has never taken on the latter; leaving it for other players, who have yet
to succeed in the market place. In NFS caching works as long as there isn't
contention. Once there's contention, clients stop caching.

> Let's start simple with actual cases...
> 
> Two (or more) clients are contending for the same page. One obtains a
> byte range delegation but with an immediate recall notice. It holds on
> to it until the page has been accessed (or until one lease period has
> elapsed) then returns the delegation on that page. The next client then

Just because a lease period has elapsed doesn't mean the page has been
accessed. Just because the page has been accessed doesn't mean forward progress
is made. Although for an operating system with real time scheduling it
might be sufficient to assert that if a processed has been dispatched for
N units of time, that is a guarantee of forward progress. That may be
the solution.

Holding onto the page for the lease period in face of contention strikes
me as very undesirable.

> gets the delegation, etc... Where do you think there is a problem with
> making progress in this scenario?

How does an NFS file system plugged into a file system switch know that
the mmapped file has been accessed? Only the processor, the memory, and 
all physical components in between the two know, and they know nothing
about NFSv4.x, though I can imagine extensions to hardware that efficiently
mark when an instruction has completed its memory access.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4



[prev in list] [next in list] [prev in thread] [next in thread]