Subject: RE: LOOKUP vs OPEN in NFSV4

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 8 Jul 2001 05:08:48 -0700

I don't see how the special stateid's have any role 
in providing UNIX advisory lock semantics. If the 
clients use normal stateids, the server can implement 
advisory locking quite simply.  For a file in which
only advisory locks are present (or the server only
supports advisory locks), such locks don't prevent
IO operations.  When the server supports mandatory
locks and they exist on a give file, those same
normal stateids also allow the server to respond
appropriately, since he has knowledge of which
lockowner is trying to do the IO and can match
that up with the lcoks held.

-----Original Message-----
From: Frank Filz [mailto:[email-masked]]
Sent: Saturday, July 07, 2001 8:44 PM
To: [email-masked]
Subject: Re: LOOKUP vs OPEN in NFSV4

Brent wrote:
> 
> "Noveck, Dave" wrote:
> > 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.
> 
> 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.

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

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

---

From: Martin Pool <[email-masked]>
Date: Fri, 20 Jul 2001 17:06:08 +1000

On  8 Jul 2001, "Noveck, Dave" <[email-masked]> wrote:

> I don't see how the special stateid's have any role in providing
> UNIX advisory lock semantics. If the clients use normal stateids,
> the server can implement advisory locking quite simply.  For a file
> in which only advisory locks are present (or the server only
> supports advisory locks), such locks don't prevent IO operations.
> When the server supports mandatory locks and they exist on a give
> file, those same normal stateids also allow the server to respond
> appropriately, since he has knowledge of which lockowner is trying
> to do the IO and can match that up with the lcoks held.

When I read it, I imagined a machine serving both Windows and Unix
clients.  With the current standard setup of Samba and NFS2|3, the
Windows machines can have mandatory SMB locks and the Unix clients can
still read the files out from underneath them.  This is arguably a
feature, since (overgeneralizing) Windows machines are trigger-happy
about locking, and Unix programs almost never expect to do locking.  I
think you can configure Samba to map Windows locks into Unix mandatory
locks, but most people don't use that.

If all the clients were using NFSv4 then there would be no back door
for the Unix clients to avoid the locks, which would cause problems
with (say) tarring up a directory while Windows clients are using it.
In short, since the two systems use locking so differently, you need
the protocol to at least have the possibility of a back door.

I'd be interested to hear if this is the scenario Brent & co had in
mind when they added the special stateids.

-- 
Martin 
VA Linux Systems

---

From: Brent <[email-masked]>
Date: Fri, 20 Jul 2001 00:25:59 -0700

> mind when they added the special stateids.

David Robinson came up with the special stateids.  
Yes, I believe their intent was to preserve file
access behavior that UNIX users are accustomed to.

   $ cat foo
   Resource temporarily unavailable
   $ %&@*$!

	Brent