From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 07/03/01-06:59:47 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E333354D5@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: LOOKUP vs OPEN in NFSV4 Date: Tue, 3 Jul 2001 04:59:47 -0700 Well, if you do a LOOKUP or OPEN, you (the client) has to be interested in the result, while for some other operations that change the current filehandle, this may not be the case. So I would not extend this to any other ops. As far as the chances of making such a change, they aren't very great because most people within the working group are satisfied with the GETFH approach. The size of the change isn't the issue. -----Original Message----- From: Som [mailto:somenathb@yahoo.com] Sent: Tuesday, July 03, 2001 12:06 AM To: Noveck, Dave; nfsv4-wg@sunroof.eng.sun.com Subject: RE: LOOKUP vs OPEN in NFSV4 --- "Noveck, Dave" <Dave.Noveck@netapp.com> wrote: > Som wrote: > > 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. > > 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/
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:53 AM Z CST