Date: Thu, 9 Sep 2010 00:28:03 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: David Brodbeck <gull@gull.us> Cc: freebsd-fs@freebsd.org, pjd@freebsd.org Subject: Re: Weird Linux - FreeBSD/ZFS NFSv4 interoperability problem Message-ID: <139628434.645718.1284006483409.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <AANLkTi=QJ2qtLvo_B-k8PXSARp_U2MxHjHwqbFYh9dip@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_645717_56228502.1284006483407
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
>
> 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
------=_Part_645717_56228502.1284006483407
Content-Type: text/x-patch; name=nfsdport.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=nfsdport.patch
LS0tIGZzL25mcy9uZnNkcG9ydC5oLnNhdgkyMDEwLTA5LTA4IDIyOjIzOjEwLjAwMDAwMDAwMCAt
MDQwMAorKysgZnMvbmZzL25mc2Rwb3J0LmgJMjAxMC0wOS0wOCAyMjo0Nzo1OC4wMDAwMDAwMDAg
LTA0MDAKQEAgLTcwLDggKzcwLDcgQEAKICNkZWZpbmUJTkZTVk5PX0NNUEZIKGYxLCBmMikJCQkJ
CQlcCiAgICAgKChmMSktPmZoX2ZzaWQudmFsWzBdID09IChmMiktPmZoX2ZzaWQudmFsWzBdICYm
CQkJXAogICAgICAoZjEpLT5maF9mc2lkLnZhbFsxXSA9PSAoZjIpLT5maF9mc2lkLnZhbFsxXSAm
JgkJCVwKLSAgICAgIWJjbXAoKGYxKS0+ZmhfZmlkLmZpZF9kYXRhLCAoZjIpLT5maF9maWQuZmlk
X2RhdGEsCQlcCi0gICAgICAgICAgICAoZjEpLT5maF9maWQuZmlkX2xlbikpCisgICAgICFiY21w
KCYoZjEpLT5maF9maWQsICYoZjIpLT5maF9maWQsIHNpemVvZihzdHJ1Y3QgZmlkKSkpCiAKICNk
ZWZpbmUJTkZTTE9DS0hBU0goZikgCQkJCQkJCVwKIAkoJm5mc2xvY2toYXNoWygqKCh1X2ludDMy
X3QgKikoKGYpLT5maF9maWQuZmlkX2RhdGEpKSkgJSBORlNMT0NLSEFTSFNJWkVdKQo=
------=_Part_645717_56228502.1284006483407--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?139628434.645718.1284006483409.JavaMail.root>