Subject: RE: LOOKUP vs OPEN in NFSV4

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 2 Jul 2001 08:34:22 -0700

Som wrote:
> Few questions on this:
>
> 1.I don't find a use of LOOKUP for NFSV4 clients. Why
> should a NFSV4 client use LOOKUP to obtain a
> filehandle when OPEN can also generate a filehandle? 
> 
> I understand that LOOKUP is there for NFSV3 and older
> clients, but is there a real use of it in NFSV4?

No.  NFSV3 servers are there for NFSV3 clients.

NFSV4 clients will use lookup when then need a filehandle
and they are not opening a file.  An example might be to
implement a UNIX stat call.  Using OPEN for this purpose
would have the following undesirable effects:

     The client would need an extra request to do a
     CLOSE, to undo the effects of the OPEN.

     Handling on the client and the server is going to
     be more complicated and expensive.

     Since OPEN is a sequenced request, only one can be
     outstanding for a given lockowner at a time, which
     may be an issue for multi-threaded apps.

     An OPEN will fail if you do not have permission to
     read or write the file, which is not what you want
     if you just want to do a GETATTR on it.

     An OPEN will be denied if someone else has the file
     open and that lockowner specified DENY=ALL.

     An OPEN will prevent someone else opening the file
     DENY=ALL, when that is not want you want to happen.

     Some servers (e.g. Windows-derived) prevent the deletion
     or renaming of an open file.

> 2. With the introduct of OPEN/CLOSE in NFSV4, its a
> stateful server...Doesn't it make a very complex NFSV4
> implementation if the same server has to handle
> stateless requests ( e.g. clients using LOOKUP
> returned filehandle ) from the same NFSV4 clients?

I think every protocol contains some stateless requests.
Unless there is some value in adding stateful features
to them, they are best left as they are.  It is 
possible that caching-related stateful features could 
usefully be added to LOOKUP and GETATTR, but my
sense is that V4 has gone as far in the direction of
statefulness as it could have, given that we need to
maintain simple recovery from server failures.

Another related issue is whether some of the infra-
structure that is used for stateful requests might have
been used more universally.  For example, sequence
numbers and lockowners (which would have to be generalized 
to be general request sequencing objects) might have been 
made universal and done on a request level, rather than on
an operation basis.  DAFS is an NFS-v4 variant that has 
gone a considerable distance in this direction in that
the requirement for specific stateful-request sequencing
has been obviated by requring more quarantees from the
transport and using sequence numbers in a general header
for all requests, allowing the response cache to be brought
within the protocol and made dependable.  My feeling is that
this has been a successful approach.  One of the interesting
questions for the future of NFS is whether similar approaches
might be applied in the less constrained wider-area environment,
but that would be something that would only be worth
considering for NFS-v5 and that's a long way off, if it ever 
happens.

> 3. Why don't the structure OPEN4resok contain the OPEN
> generated filehandle instead of client doing one more
> GETFH and getting the same filehandle? It atleast
> reduces one operation for each open! 

Actually, I think OPEN and LOOKUP should directly return
the filehandle (and not just when the op succeeds), but 
this is very much a minority opinion in the working group.

V4 only returns handles via GETFH.  Ops that produce
filehandles only change the current filehandle and there
is a value in having that kind of uniformity.

The reason I think that LOOKUP and OPEN should return
filehandles has to do with the handling of multi-component
lookups/opens.  If a lookup encounters a symlink (or some
other error situation), you'd like to be able to restart 
the process at the point of failure, which means that you 
need the filehandle where you stopped.  A COMPOUNDEDed
GETFH can't do it, since the error stops the request,
preventing the GETFH from being executed.  This makes 
multi-component lookup/open kind of useless in any 
environment where symlink might be encountered.

---

From: Som <[email-masked]>
Date: Mon, 2 Jul 2001 21:06:02 -0700 (PDT)

> environment where symlink might be encountered.

So, now that we have a very good reason to return
filehandle as part of OPEN4resok structure , applying
the same consistency rule ( :-) ) , why not return
filehandles for every state modifying operations? I
mean whenever client has to do GETFH, why not just
return the result always in OPEN4resok strucutre? 

Since NFSV4 is a very new protocol from earlier
versions this change should be possible to do....this
also saves considerable amount of wire traffic...is
this too big a change for NFSV4?

thanks, som.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: Som <[email-masked]>
Date: Mon, 2 Jul 2001 21:20:00 -0700 (PDT)

>      DENY=ALL, when that is not want you want to
Consider this example:
The OPEN owner has specified SHARED ACCESS = DENY ALL,
and an application which has access to the file using
filehandle returned by LOOKUP...
In this case, will the server allow access to the
file( read/write) when LOOKUP returned filehandle is
presented? I feel it should not, but in the example of
yours it looks like it will...which one is true?

thanks, som.

---

From: Martin Pool <[email-masked]>
Date: Tue, 3 Jul 2001 14:21:56 +1000

On  2 Jul 2001, Som <[email-masked]> wrote:

> > The reason I think that LOOKUP and OPEN should return filehandles
> > has to do with the handling of multi-component lookups/opens.  If
> > a lookup encounters a symlink (or some other error situation),
> > you'd like to be able to restart the process at the point of
> > failure, which means that you need the filehandle where you
> > stopped.  A COMPOUNDEDed GETFH can't do it, since the error stops
> > the request, preventing the GETFH from being executed.  This makes
> > multi-component lookup/open kind of useless in any environment
> > where symlink might be encountered.

Actually I think a COMPOUNDed GETFH can do that perfectly well.  The
RFC has an example where you do

               PUTFH  (directory filehandle)
               LOOKUP "pub"
               GETFH
               LOOKUP "foo"
               GETFH
               LOOKUP "bar"
               GETFH

If any of these components are symlinks, then that operation will fail
and the client will have filehandles for all the previous directories.
This does mean you get filehandles for all previous directories as
well, but it's probably pretty useful to stick them into a cache
anyhow.

> So, now that we have a very good reason to return filehandle as part
> of OPEN4resok structure , applying the same consistency rule ( :-) )
> , why not return filehandles for every state modifying operations? I
> mean whenever client has to do GETFH, why not just return the result
> always in OPEN4resok strucutre?
> 
> Since NFSV4 is a very new protocol from earlier versions this change
> should be possible to do....this also saves considerable amount of
> wire traffic...is this too big a change for NFSV4?

I don't understand why you say it would generate more wire traffic.
Remember that the GETFH can be compounded with the OPEN.  Returning
filehandles on every call would add up to 132 bytes of filehandle data
to every single (state-modifying) response, whereas sending a GETFH
takes only one word more in the request, no more round trips, and
doesn't impose a burden on clients who don't need the information.  I
can imagine clients who keep track of files by name rather than fh,
and always send LOOKUP and never call GETFH.

-- 
Martin 
VA Linux Systems

---

From: Som <[email-masked]>
Date: Tue, 3 Jul 2001 23:17:58 -0700 (PDT)

> considering for NFS-v5 and that's a long way off, if

Yes, request-id part of the DAFS protocol header is
definitely something useful and several features can
be developed using this. One of them could be ( in
future ), DAFS working over unreliable media ( like
WAN ). One possible DAFS enhancement: ability to
retransmit non-idempotent requests ( use the same
request-id so server knows its a retransmit ).

On NFSV4 front:
How does NFSV4 server handles retransmission of
non-idempotent requests by client? Will server
erroneously re-execute the retransmitted
non-idempotent request?

thanks, som.

Reference discussion:
Something similar to this has been discussed in DAFS
mailing list at
http://groups.yahoo.com/group/dafs-discussions/message/248?threaded=1

=====
"Chess holds its master in its own bonds,
shackling the mind and brain so that the 
inner freedom of the very strongest must 
suffer"-Albert Einstein

---

From: Brent <[email-masked]>
Date: Sat, 07 Jul 2001 15:04:33 -0700

> erroneously re-execute the retransmitted

The NFSv4 protocol doesn't protect servers from
re-execution of retransmitted non-idempotent ops.

Like NFS v2 and v3, v4 servers will need to use
a duplicate request cache to reduce the chance of
erroneous reply.  Locking ops are protected by
sequence numbers, but directory ops are not, so
a retransmitted REMOVE or RENAME may return an
error.

	Brent