Subject: Re: [nfsv4] location_info

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 9 Sep 2005 14:49:42 -0400

Well, in DFS you'd get the currency and the version (and the fsid) back
from every RPC from the server, whether a data fetch or a readdir.
Carl's right in that these are fsid-wide attributes.  The client
probably wants to know their values at failover time, but ideally if
there's a fsid-wide version identifier that's monotonically increasing,
then it might want to be part of a set of attrs returned more
frequently, like in the fattr4, from several operations.  Perhaps that's
what Carl meant.
 
It's useful to have a version when switching replicas, so that the
client doesn't inadvertently incorporate (and present to applications)
any data that has possibly been obsoleted by a change in a later version
that an application could have observed.  DFS used the version all the
time as a cheap cache control mechanism for "read-only" data, since it
would never grant or revoke real tokens (delegations) for such data.
Perhaps if the NFSv4 model for handling read-only data includes real
delegation grants to clients, it's important for a server to do those
delegation recalls, and less important for the client to keep aware of
the data version, assuming the server will be doing the recalls
correctly.
 
        Craig 
 
 ---- Original message text ----
 
To: Ted Anderson <TedAnderson at mindspring.com>
Subject: Re: [nfsv4] location_info
From: Carl Burnett <cburnett at us.ibm.com
<mailto:[email-masked]> >
Date: Wed, 31 Aug 2005 16:22:55 -0500
Cc: nfsv4-bounces at ietf.org
 
I prefer the notion of a new fsid wide attribute, since it can become 
stale shortly after being communicated to clients in locations info. The

client will want to query it anyway from each candidate server at
failover 
time to find a suitable candidate. This also avoids the requirment for a

server to depend on knowing each peer's version info in order to service
a 
locations request.
 
Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett at us.ibm.com)

From: Ted Anderson <TedAnderson at mindspring.com> 
Date: 08/31/2005 09:45 AM
To: nfsv4 at ietf.org
cc: Jon Haswell/San Jose/IBM at IBMUS, "Noveck, Dave" <Dave.Noveck at
netapp.com>
Subject: Re: [nfsv4] location_info
 
On 8/30/2005 17:12, Jon Haswell wrote:
> Yes, that would certainly work, my only thought for putting it in the
> location_info field would be to avoid creating just one more
attribute.
> Your suggested names also is kind of fun.
One valuable use for the replica version number does relate to replica
selection. A feature of DFS is that even though a client may
unavoidably deliver inconsistent data to an application when
transitioning from an older replica to a newer one, the client
guarantees never to provide data from an older replica. This means the
age of data is always monotonic increasing.
To implement this the client queries the replica server and compares
replica (in the DFS case: fileset) version numbers and ignores replicas
whose version number is older than the latest version it has ever
fetched a file from.
In the NFSv4 case, this replica attribute could be part of location_info
or a new per filesystem attribute (e.g. fs_provenence). The client
would need to be able to make relational comparisons on them, however,
so a number would be better than a string. In this connection,
certainly, 64 bits would be better than 32. This would also be
compatible in size with the change attribute and sufficient for a
replica version number, though 96 bits would be necessary to contain an
nfstime4.
Ted
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4