Subject: RE: Replication/Migration issues list

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 4 Oct 2002 17:27:35 -0700

Robert Thurlow wrote: 
> Ted wrote:
>
> > A filesystem version number helps the NFS client provide better
> > semantics in several ways.  The basic idea is that each replica has a
> > single number that identifies which version of the filesystem it is
> > providing and clients track this number.  Whenever the number changes
> > the client knows that the replica has been updated and can immediately
> > mark all its cached content from that replica for revalidation.  This
> > insures that an application never sees data that goes backward in time,
> > in the sense that it might reference one file from replica N and
> > subsequently reference another file from replica N-1.

> I see the value, but this is pretty different from current
> NFS consistency semantics, so I wonder how much interest
> there will be in this direction.

For me there are two sources of interest.

First, I think this is an interesting facility even within the confines
of fairly standard NFS implementations.  To see that, just turn Ted's 
statement around.  Rather than, "Whenever the number changes the 
client knows that the replica has been updated and can immediately 
mark all its cached content from that replica for revalidation.", 
how about, "When the client checks the number and sees that it 
hasn't changed, it knows that the filesystem has not been updated 
and so it does not have to do any revalidation of individual cached 
objects."  Where this would be particularly useful is environments 
in which many objects are cached, such as a caching proxy which wants  
to keeps tons of cached objects on disk, but would rather not revalidate
or maintain enormous numbers of read delegations.  When nothing 
is changing, a quick "Has anything changed", would be a great
benefit.

I also think (somewhat more speculatively) that if we are thinking
of clients that have multiple potential sources for the same 
file system data, you are going to be confronted with exactly the
issues that this approach would deal with.  The client, when it
switches from one replica to another can completely discombobulate
applications if time appears to go backward, i.e. you fetch a block
of a given file and then later fetch a block that was from a
an earlier version of that file.  Preventing this has never been
part of the NFS consistency model, because it came for free.
Given one client and one server (and assuming standard physics,
i.e. no superluminal relative motion) the client is not going
to see time go backwards, so nothing is needed to prevent it in 
those more standard environments.  In more complicated environments
in which failing over to another replica is possible, this 
semantic doesn't come for free.

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 10 Oct 2002 12:53:20 -0600 (MDT)

Ted wrote:

> > > semantics in several ways.

Dave wrote:

> statement around ... [to] 
> "When the client checks the number and sees that it 
> objects."

Thanks, that helped - and I agree this is interesting.  We'd
need to work out lots of semantics, but I will keep this on
the table as something to work on (I guess mostly as an NFSv4
core protocol feature for a future minor version).

Rob T