From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 07/01/02-10:06:08 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A8ED9@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: Minor Inter-operability stuff Date: Mon, 1 Jul 2002 08:06:08 -0700 The last reply was incomplete (hit send when I shouldn't have). This should be read in preference to that. > I've been doing some testing of the Univ. of Michigan Linux V4 client against > my server and I've bumped into the following: > > - The argument to LOOKUP has changed from a "pathname" to a "component". Is > this a permanent change to RFC3010? I guess nothing is permanent until we go through Proposed Standard (again). Draft Standard, and Standard, but I certainly expect things to stay that way. This first happened in the Nov 2001 spec, which has been the basis for bakeoff and other interoperability testing for a while. We're trying to shut down incompatible protocol changes. I know there's one in the latest spec (http://www.nfsv4.org/rfc3010updates/draft-01-04/draft-ietf-nfsv4-rfc3010bis-01-04.txt) and there may have been a few others between Nov 2001 and now. See http://www.nfsv4.org/rfc3010updates/index.html for the recent spec history. I believe that the new spec will be what is tested at the bakeoff in August. Although there may be clarifications and a few new error codes in subsequent the revisions, the message formats will not change past that point, barring something absolutely extraordinary happening. A number of people have said things on the order of "Over my dead body", anyway. As I recall, the change of LOOKUP to a component happened when people started to ask for information about partially successful lookups and wouldn't it be nice if they could get information about how far it got that allowed them to resume the lookup (after interpreting a symlink, for example), rather than an unhelpful "Gee your lookup failed". When satisfying those people started to make LOOKUPres kind of repulsive, it was pointed out that COMPOUND allowed them to decide the information they got by doing multiple single-component lookups. At which point the idea of LOOKUP taking a pathname seemed kind of useless since it was only for those who wanted to do a multiple-component lookup and did not want any intermediate results in the event of partial success, and it wasn't clear such people existed. > - The Linux client wants the RAWDEV attribute to be returned for what seems > like all files/directories. Does this make sense for non-special files? > (and what should it be? The same as fsid?) My server has always returned zero for RAWDEV for non-special files and the Linux client had no problem. I'm guessing but I bet a random number would do as well. > - a symlink op has no attributes associated with it. (Most V2/3 clients do > seem to provide a mode.) The philosophy is that if you want attributes, do a GETATTR as part of the COMPOUND. ... > Now, for a couple that I'm not so sure about w.r.t. semantics. > - Unless I disable callbacks, the client sometimes hangs waiting for a > callback during writing of large files. (My server doesn't do callbacks > yet and I haven't figured out quite what is going on w.r.t. delegation. > Are callbacks only expected when Delegation occurs?) Callbacks are only expected when delegation occurs. However, even when callbacks are expected, the client shouldn't wait one. It is up to the server when to recall a delegation. The cleint can return a delegation that even if it has not been recalled. ...
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:54 AM Z CST