From owner-freebsd-fs@FreeBSD.ORG Sat Sep 4 00:55:08 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 C68B610656A6 for ; Sat, 4 Sep 2010 00:55:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2DC8FC22 for ; Sat, 4 Sep 2010 00:55:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAP41gUyDaFvO/2dsb2JhbACDGJ5xrUiRbYRIcwSKGQ X-IronPort-AV: E=Sophos;i="4.56,316,1280721600"; d="scan'208";a="92791484" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 03 Sep 2010 20:55:07 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6AC7BB3F25; Fri, 3 Sep 2010 20:55:07 -0400 (EDT) Date: Fri, 3 Sep 2010 20:55:07 -0400 (EDT) From: Rick Macklem To: David Brodbeck Message-ID: <929991361.487274.1283561707352.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_487273_1760299342.1283561707351" 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 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: Sat, 04 Sep 2010 00:55:08 -0000 ------=_Part_487273_1760299342.1283561707351 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > Here's a capture for you. This is a Linux client (192.168.30.30) > working against a FreeBSD 8.1-RELEASE server (192.168.30.102). If you > need a capture using FreeBSD 9, that'll require some more setup on my > part and I won't be able to get to it until Monday. Ok, The server is returning NFS4ERR_OLD_STATEID, which means that the seqid# inside the stateid is out of date. I think the original intent of this was to be a debugging aid for client writers, but a discussion on the nfsv4 mailing list pretty much concluded that it was useless. (It is definitely the case that the server doesn't care. A separate seqd# is used to order the open/lock/close ops.) So, please try the attached little patch that just disables the server check for this case for Close. (The line #s will be different than 8.1, but all it is doing is commenting out the test for this case in nfsrv_openupdate(), if the patch won't apply directly.) I'm almost at the point where I'll just disable all the cases that generate NFS4ERR_OLDSTATEID in the server. (It is already disabled for Read/Write/Setattr of size unless you tweak a variable.) Please let me know if it helps, rick ------=_Part_487273_1760299342.1283561707351 Content-Type: text/x-patch; name=nfsdstate.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfsdstate.patch LS0tIG5mc19uZnNkc3RhdGUuYy5zYXYJMjAxMC0wOS0wMyAxOTozNTo0NC4wMDAwMDAwMDAgLTA0 MDAKKysrIG5mc19uZnNkc3RhdGUuYwkyMDEwLTA5LTAzIDE5OjQwOjQwLjAwMDAwMDAwMCAtMDQw MApAQCAtMjg3Myw5ICsyODczLDExIEBACiAJaWYgKCFlcnJvcikKIAkJZXJyb3IgPSBuZnNydl9j aGVja3NlcWlkKG5kLCBuZXdfc3RwLT5sc19zZXEsCiAJCSAgICBzdHAtPmxzX29wZW5vd25lciwg bmV3X3N0cC0+bHNfb3ApOworI2lmZGVmIG5vdG5vdwogCWlmICghZXJyb3IgJiYgc3RwLT5sc19z dGF0ZWlkLnNlcWlkICE9IG5ld19zdHAtPmxzX3N0YXRlaWQuc2VxaWQgJiYKIAkgICAgIShuZXdf c3RwLT5sc19mbGFncyAmIE5GU0xDS19DT05GSVJNKSkKIAkJZXJyb3IgPSBORlNFUlJfT0xEU1RB VEVJRDsKKyNlbmRpZgogCWlmICghZXJyb3IgJiYgdm5vZGVfdnR5cGUodnApICE9IFZSRUcpIHsK IAkJaWYgKHZub2RlX3Z0eXBlKHZwKSA9PSBWRElSKQogCQkJZXJyb3IgPSBORlNFUlJfSVNESVI7 Cg== ------=_Part_487273_1760299342.1283561707351--