From owner-freebsd-fs@FreeBSD.ORG Thu Sep 9 04:28:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6D6C10656AE; Thu, 9 Sep 2010 04:28:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5438FC15; Thu, 9 Sep 2010 04:28:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC//h0yDaFvO/2dsb2JhbACDGZ8DrRSRWYRJdASEeoUl X-IronPort-AV: E=Sophos;i="4.56,337,1280721600"; d="scan'208";a="91231302" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Sep 2010 00:28:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 84BB9B3EA8; Thu, 9 Sep 2010 00:28:03 -0400 (EDT) Date: Thu, 9 Sep 2010 00:28:03 -0400 (EDT) From: Rick Macklem To: David Brodbeck Message-ID: <139628434.645718.1284006483409.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_645717_56228502.1284006483407" X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org, pjd@freebsd.org Subject: Re: Weird Linux - FreeBSD/ZFS NFSv4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 04:28:05 -0000 ------=_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--