Subject: LOOKUP vs OPEN in NFSV4

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

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?

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?

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! 

thanks, som.

=====
"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

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

---

From: Martin Pool <[email-masked]>
Date: Mon, 2 Jul 2001 17:41:30 +1000

> Few questions on this:

These are my interpretations; Brent can give better answers.

> filehandle when OPEN can also generate a filehandle? 

Well, the RFC seems to suggest that since OPEN creates state on the
server clients should use LOOKUP if possible so as to be gentle.
Also, the encoded LOOKUP call is considerably smaller than the OPEN
call.

> I understand that LOOKUP is there for NFSV3 and older clients, but
> is there a real use of it in NFSV4?
 
> returned filehandle ) from the same NFSV4 clients?

Certainly having a stateful server is more complex than not.  Of
course in earlier versions much of this complexity was present, but
split into rpc.lockd and rpc.statd, which certainly made it more
confused at the network level.  Once the server is stateful, I don't
think adding support for lightweight stateless operations makes it
much worse.  Servers which don't support locking can ignore much of
this stuff.

> reduces one operation for each open! 

Putting in a GETFH makes the request only four bytes larger (I think),
which is an acceptable cost for making the protocol consistently only
return externalized filehandles on request, not on every operation.

-- 
Martin 
VA Linux Systems                        GnuPG encrypted email preferred

---

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

--- Martin Pool <[email-masked]> wrote:
> > 2. With the introduction of OPEN/CLOSE in NFSV4,
its
> a

I haven't see a network filesystem protocol where its
READ/WRITE routines can be called with two type of
filehandles ( one returned by LOOKUP style stateless
filehandle and the other one returned by OPEN style
stateful filehandle )....Probably NFSV4 derivative
DAFS is the only other protocol which has the same
feature...

I agree with the usage example given by you and
Dave...LOOKUP can be used to get file attributes etc
and that's a good example. But LOOKUP can be misused
to READ/WRITE files confusing the stateful semantics
of servers.

thanks, som.

=====