[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Minor Inter-operability stuff
From:       rick () snowhite ! cis ! uoguelph ! ca
Date:       2002-06-30 23:52:30
Message-ID: 200206302352.TAA08712 () snowhite ! cis ! uoguelph ! ca
[Download RAW message or body]

Hi,

I've cc'd the main nfsv4-wg, since some of these are things others might
have opinions on, or maybe be interested in hearing about.

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?
- 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?)
- a symlink op has no attributes associated with it. (Most V2/3 clients do
  seem to provide a mode.)
- "ls -l" works ok, except it reports a "total N", where N is usually 0.
  (I suspect the client isn't filling in st_blocks. So what should be used
   as a blocksize? In my as yet untested client, I used maxread.)
- If my server is down for a while (it did lots of this until recently:-),
  when it comes back, there is a flood of renew ops. (Seems to me that one
  would be enough?)

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?)
- At the beginning of the old connectathon basic test8, the client gets
  upset when an inode changes from 100666->120755 (from a regular file to
  a symbolic link). I know the fileid has been reused with a different
  generation#, which would be ok for V2/3. For V4, should something else
  change when a node (fileid#) is reused? Are File Handles still T stable?
  (That seems to be vaguely hinted at in RFC3010, section 4.)

Oh, and I assumed the NFS4ERR_EROFS return value for Openattr is just a
typo for NFS4ERR_ROFS?

Well, anyhow, in case you're curious, my server now runs the cthon test
suite (except I have to run test8 by itself, due to the above) and an
assortment of other things, talking to the Univ. of Michigan client.
(Current patch on Linux-2.4.18.) I've still got lots to do, since locking
is still faked and I haven't figured out what a stateid really is yet, but
it's getting there. (My client is just code that compiles, but hasn't been
tested.)

Thanks in advance for any help with the above and how you find it useful, rick


[prev in list] [next in list] [prev in thread] [next in thread]