Subject: RE: LOOKUP vs OPEN in NFSV4

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 3 Jul 2001 05:10:07 -0700

Regarding my example, my assumption was the
operations that you would do with the filehandle
you got from LOOKUP would not include READ or
WRITE.

Normally, the reason that you can't just do a
LOOKUP and then a READ or WRITE has to do, not
with the nature of the filehandle, but with the
fact you have no stateid.

Unfortunately, the spec currently allows you to
do READ and WRITE with "special" stateids, all
zeros and all ones.  It's not clear to me why
these exist.  Unless there's a good reason for
them, I would hope these get deleted.  I think 
this issue is on Spencer's to-do list.

As the spec stands, deny=all will prevent reads
and writes done with an all-zero stateid (and you 
can't get a normal stateid via OPEN if someone 
else has done deny=all).  This leaves a stateid of 
all ones and the spec does say that someone can do 
a READ (though thankfully not a WRITE) under these
circumstances :-(

-----Original Message-----
From: Som [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 12:20 AM
To: Noveck, Dave; [email-masked]
Subject: RE: LOOKUP vs OPEN in NFSV4

--- "Noveck, Dave" <[email-masked]> wrote:
> 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.
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.

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

---

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

> this issue is on Spencer's to-do list.

Well, one of the goals of the protocol was that it
be possible to reach out over the Internet and grab a 
file from a server with a minimum of interaction.

For instance, with the HTTP protocol you can issue
a "GET" request and get a file in a single turnaround
(once the TCP connection is established).  Whereas with
NFS versions 2 and 3 you had that tacky MOUNT protocol
and even with WebNFS you still had to issue a separate
LOOKUP request to retrieve a filehandle before you could
issue a READ.

So, we're speculating that v4 might have clients that
are not concerned about cache consistency or exclusive
access, e.g. an image viewer or MP3 player.

Currently, it's possible for those clients to set up
a connection and generate a single compound request
that can lookup the file,  grab its attributes, and its
data, in a single request.

	Brent

---

From: Frank Filz <[email-masked]>
Date: Sat, 07 Jul 2001 20:43:43 -0400

> data, in a single request.

Aren't the special state-IDs also required to duplicate UNIX advisory
lock semantics?

-- 
Frank Filz
IBM Storage Systems
[email-masked]