Subject: RE: fileid in NFSv4

From: [email-masked]
Date: Fri, 2 Jun 2000 08:43:27 -0700

> I was thinking that if you have 2 filehandles that are different on a
> server for which the unique_handles == FALSE, you might still want to
> use the fileid to group the files together in order to try to ensure
> local cache consistency.

That's the intent.

> This however impossible if the fileid is a volatile quantity.

I hope you don't mean what I would mean by "volatile quantity",
i.e. one that changes (for a given file) from time to time.  There
isn't much you can do with a fileid that doesn't stay the same.

If you are referring to the fact that the same fileid may be
reassigned so that it designates one file and then later a 
second file, after the first file has ceased to exist, then this
is not a fatal problem.

Although I see it isn't as clear as it should be, the idea behind
the identity test in section 9.3.4 is that it allows you to test
for the identity of the objects designated by two distinct handles,
subject to the proviso that such objects exist.  If either or
both of the handles is stale, the result is undefined.  When using
this test to implement locally coherent caching, you need to work
around the problem of stale handles (which can lead to two cached
fileid's being the same when there is no actual identity of the
objects designated by the handles).

Consider the case of an OPEN which returns handle A that has
associated fileid X.  Suppose you find handle B with the same
server, fsid, and fileid X, and suppose there is associated
cached data.  If you take the attributes that you got after
the OPEN and compare the change attribute with the one saved
and associated with handle B, you will probably note a mismatch
and flush the cache.  In fact, if the change attribute were
implemented as modified time, you would have to see a mismatch
since A was created after B ceased to exist.  Given that
there are no inter-file coherence constraints on the change
attribute, it is possible see the same value.  In this case,
the best thing to do is revalidate handle B.  If it is stale,
flush it.  If it isn't, than A and B denote the same object.

You make file identity decisions when open presents you with a
new handle that you can start caching data on.  When an existing
handle has data cached and it might be the same object (according
to the procedure in 9.3.4), you may need to verify that the 
old hanlde still denotes an existing object.  Once those two
handles have been tied together as denoting the same object,
then they continue to do so, as long as we still make reference
to those handles.  Also, as in the example above, other circumstances
such as change attribute mismatches, mean that you don't actually
have to revalidate the handle.  The number of times you are actually
going to have to do this is going to be very small.

> So if I understand correctly, your answer seems to be that caching has
> to be on a per-filehandle basis, and hence unique_handles == FALSE
> means that the client cannot expect to maintain a consistent cache for
> 2 hard links to a single file?

I think it can, if the server provides fileid's.  If it doesn't and
unique_handles == FALSE, then it cannot maintain even a locally coherent
cache.

---

From: Brent Callaghan <[email-masked]>
Date: Fri, 2 Jun 2000 15:24:52 -0700 (PDT)

vahalia@emc writes:
> Finally, in nfsv2 and nfsv3, the only time one could have multiple
> different handles for the same file (at least for Unix-based servers)
> was if the client came through different mount points.  I know nfsv4
> moves away from the notion of mounts.  Does this mean that the servers
> will return different handles for the same file more capriciously?

No, not deliberately, but a server may be unaware that it has
already returned a different filehandle for the same file.

A good example is the volatile filehandles.  NFSv4 attempts to make
it easier to build user-level servers.  A user-level server doesn't
easily have access to APIs that allow it to map an fsid/fid pair
to a file descriptor.  Instead, it may embed a pathname in the
filehandle.  A client could lookup the same file through two
different pathnames - hence get two different filehandles for
the same file.

	Brent