Subject: RE: recovery from NFS4ERR_FHEXPIRED

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 27 Sep 1999 06:47:11 -0700

> I think maybe an earlier reply of mine got lost.
> I've appended it to the end.
> 
> So, is a file handle a 128-bit inode number,
> or is it a 128-bit file descriptor? For a lot
> of reasons, I believe it is (or should be)
> more the latter -- a "handle", a rendevouz
> between the client and the server.
> 
> We all seem to be jumping through
> countless hoops trying to preserve
> file handles as file identities (128-bit
> inode numbers). Give it up, and the
> hoops all go away. Don't EVER worry
> about file identity. Give up st_ino and
> st_gen also, as they are problematic
> or impossible for some server/file
> models. OBTW, I believe a great
> many cache issues get simpler
> with the "file descriptor" model.
> They sure do for SMB.

It seems to me that if you can't tell if whether
two handles refer to the same object, cache issues
become very simple.  You can't cache on the client
because any write to any file might be a write to
any other file you have cached.  So you might as
well not cache on the client.  This simplifies things
but I think this is case where "evrerything should
be as simple as possbile, but not more so."

This basically creates the protocol equivalent of
the C pointer-aliasing problems.  Handles are like
pointers and you have a choice between a very simple
but poorly-performing naive implementation and great
deal of complexity trying to be clever enough to 
recover information about how things are used, 
information that the model denies you.

> File semantics are the domain of the file
> server, not the protocol. A file handle
> is an opaque (means don't look at
> it ever) rendevouz between a client
> and it's server, and let no
> (overzealous) working group come
> between them ;-).

If you sent every file operation to the server,
the server-as-absolute-monarch model might make
sense.  As soon as the client can do things
locally, the server can no longer do whatever 
it chooses.  There have to be shared expectations
between the server and the client.  This doesn't
mean gratuitously restricting the possible server 
semantics but it does mean that the protocol 
definition cannot avoid some involvement with file
semantics.

---

From: Gordon Waidhofer <[email-masked]>
Date: Mon, 27 Sep 1999 10:15:57 -0700

"Noveck, Dave" wrote:
> > ... Don't EVER worry about file identity. ...
> 

The *CLIENT* can't tell if two handles refer to the
same object, ever. The only rule that makes sense
is two returned file handles which are the same
MUST refer to the same file. The server can tell
when two file handles refer to the same object.
Further, the server should be aware of potential
caching conflicts, and deny client-side caching
in such circumstances. There was a lot of discussion
a few months ago about what identity to use for
cache tags. My proposal then -- and now --
is to make a cache identity a deliberate attribute
under the control of the server, rather than
overloading file handles and attribute fields
with the cache-identity duty.

> information that the model denies you.

If you want cache identity, define it independently
of all other values.

> definition cannot avoid some involvement with file

Agreed. When the server or file model is a mismatch
for the NFS caching architecture, the server must
be able to advise the client "no caching, you'll
get it wrong."

-- 
==================================================================
  Gordon W Waidhofer                    Traakan Software, Inc.
  [email-masked]                       111 Main St., Suite #5
  650-947-1583  Direct                  Los Altos, CA  94042
  650-947-1580  Main                    http://www.traakan.com
  650-947-1588  Fax