Weird Linux - FreeBSD/ZFS NFSv4 interoperability problem

[Rick Macklem]

> 
> This seems to have changed the problem. Now I get the following error
> during checkouts:
> 
> svn: In directory 'documentation/software-notes'
> svn: Can't copy
> 'documentation/software-notes/.svn/tmp/text-base/directory-server-install-notes.txt.svn-base'
> to
> 'documentation/software-notes/.svn/tmp/directory-server-install-notes.txt.tmp.tmp':
> Input/output error
> 
> I don't see any related errors in the syslog on the client or server.
> 
Ok, your packet trace for this one pointed me at what I think is the
problem. Thanks for sending the packet traces. I wouldn't have figured
this out without them. Here's what seems to be happening:

- At packets #543-546 in the trace, there were two opens of different files
  like the above, (one ended in .tmp.tmp and the other .svn-base). The two
  files have different file handles (which they should), but were assigned
  the same open stateid (which shouldn't be the case). My code only assigns
  the same stateid if it thinks they have the same file handle. Here's the
  macro that does this...
#define	NFSVNO_CMPFH(f1, f2)						\
    ((f1)->fh_fsid.val[0] == (f2)->fh_fsid.val[0] &&			\
     (f1)->fh_fsid.val[1] == (f2)->fh_fsid.val[1] &&			\
     !bcmp((f1)->fh_fid.fid_data, (f2)->fh_fid.fid_data,		\
            (f1)->fh_fid.fid_len))
struct fid is...
struct fid {
	u_short		fid_len;		/* length of data in bytes */
	u_short		fid_reserved;		/* force longword alignment */
	char		fid_data[MAXFIDSZ];	/* data (variable length) */
};

and the zfs variant of this is...
typedef struct zfid_short {
	uint16_t	zf_len;
	uint8_t		zf_object[6];		/* obj[i] = obj >> (8 * i) */
	uint8_t		zf_gen[4];		/* gen[i] = gen >> (8 * i) */
} zfid_short_t;

can you spot the problem?

It turned out that, for these two files, the only difference in the
fids fell in the fid_reserved field of the generic one, so the macro
erroneously said they were the same file handle.

Although it would be nice if ZFS filled all of its fid into fid_data,
I suspect they needed the extra two fid_reserved bytes.

Please try the attached patch, which changes the macro so that it
compares the entire "struct fid". (I think that is safe, since I
bzero() the entire structure before calling VOP_VPTOFH().)

Again, thanks for sending the packet traces and, hopefully, this
patch will do the trick, rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfsdport.patch
Type: text/x-patch
Size: 562 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100909/bff5948b/nfsdport.bin