From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 07/08/01-07:08:48 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E333354EA@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: LOOKUP vs OPEN in NFSV4 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:ffilz@raleigh.ibm.com] Sent: Saturday, July 07, 2001 8:44 PM To: nfsv4-wg@sunroof.eng.sun.com 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 ffilz@us.ibm.com
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:55 AM Z CST