From owner-freebsd-fs@freebsd.org Thu Jul 2 23:15:41 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D02A993924 for ; Thu, 2 Jul 2015 23:15:41 +0000 (UTC) (envelope-from email.ahmedkamal@googlemail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1B7D1219; Thu, 2 Jul 2015 23:15:40 +0000 (UTC) (envelope-from email.ahmedkamal@googlemail.com) Received: by wiwl6 with SMTP id l6so210834880wiw.0; Thu, 02 Jul 2015 16:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Up9HFwc6FqCrF8j+7EeB6EkhlllyalxCpj6T/ng2YP8=; b=WlkaDabmto+JNnHaWwuuCBSRQVVBo5jYpwQpjIsuFmCjnoVYz94bq2ZcfNk5blSr0y /obPVDSYiZAkmkk012qDH4Ms/S9S66eNd62DbLuHzCzrSDcA4969FrqBz54ajhyqY8Nd 9fkgXaTQ+BGSSKSuARdqk/DHg6ZXyymXa2jbRsZbrZwZyxTsd1r0PZ60/wXmrm8lsaDd mNsTv1/Ck/IZVmBVXHIElrMTOde/rs6YeuNp0gn/V8YE8ro3Bo6znL5LaIW5Myci+9Uq N6ZjA8TR8lHLaEOuhBju7umlVsMBRs6FI0ieVCGnY/hE4KkgonWB9JwvfigV+uC5yKaW +vpw== X-Received: by 10.180.7.199 with SMTP id l7mr21553672wia.28.1435878938349; Thu, 02 Jul 2015 16:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.143 with HTTP; Thu, 2 Jul 2015 16:15:18 -0700 (PDT) In-Reply-To: <791936587.3443190.1435873993955.JavaMail.zimbra@uoguelph.ca> References: <684628776.2772174.1435793776748.JavaMail.zimbra@uoguelph.ca> <55947C6E.5060409@delphij.net> <1491630362.2785531.1435799383802.JavaMail.zimbra@uoguelph.ca> <5594B008.10202@freebsd.org> <1022558302.2863702.1435838360534.JavaMail.zimbra@uoguelph.ca> <791936587.3443190.1435873993955.JavaMail.zimbra@uoguelph.ca> From: Ahmed Kamal Date: Fri, 3 Jul 2015 01:15:18 +0200 Message-ID: Subject: Re: Linux NFSv4 clients are getting (bad sequence-id error!) To: Rick Macklem Cc: Julian Elischer , freebsd-fs@freebsd.org, d@delphij.net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 23:15:41 -0000 Thanks all .. I understand now we're doing the "right thing" .. Although if mounting keeps wedging, I will have to solve it somehow! Either using Xin's patch .. or Upgrading RHEL to 6.x and using NFS4.1. Regarding Xin's patch, is it possible to build the patched nfsd code, as a kernel module ? I'm looking to minimize my delta to upstream. Also would adopting Xin's patch and hiding it behind a kern.nfs.allow_linux_broken_client be an option (I'm probably not the last person on earth to hit this) ? Thanks a lot for all the help! On Thu, Jul 2, 2015 at 11:53 PM, Rick Macklem wrote: > Ahmed Kamal wrote: > > Appreciating the fruitful discussion! Can someone please explain to me, > > what would happen in the current situation (linux client doing this > > skip-by-1 thing, and freebsd not doing it) ? What is the effect of that? > Well, as you've seen, the Linux client doesn't function correctly against > the FreeBSD server (and probably others that don't support this "skip-by-1" > case). > > > What do users see? Any chances of data loss? > Hmm. Mostly it will cause Opens to fail, but I can't guess what the Linux > client behaviour is after receiving NFS4ERR_BAD_SEQID. You're the guy > observing > it. > > > > > Also, I find it strange that netapp have acknowledged this is a bug on > > their side, which has been fixed since then! > Yea, I think Netapp screwed up. For some reason their server allowed this, > then was fixed to not allow it and then someone decided that was broken and > reversed it. > > > I also find it strange that I'm the first to hit this :) Is no one > running > > nfs4 yet! > > > Well, it seems to be slowly catching on. I suspect that the Linux client > mounting a Netapp is the most common use of it. Since it appears that they > flip flopped w.r.t. who's bug this is, it has probably persisted. > > It may turn out that the Linux client has been fixed or it may turn out > that most servers allowed this "skip-by-1" even though David Noveck (one > of the main authors of the protocol) seems to agree with me that it should > not be allowed. > > It is possible that others have bumped into this, but it wasn't isolated > (I wouldn't have guessed it, so it was good you pointed to the RedHat > discussion) > and they worked around it by reverting to NFSv3 or similar. > The protocol is rather complex in this area and changed completely for > NFSv4.1, > so many have also probably moved onto NFSv4.1 where this won't be an issue. > (NFSv4.1 uses sessions to provide exactly once RPC semantics and doesn't > use > these seqid fields.) > > This is all just mho, rick > > > On Thu, Jul 2, 2015 at 1:59 PM, Rick Macklem > wrote: > > > > > Julian Elischer wrote: > > > > On 7/2/15 9:09 AM, Rick Macklem wrote: > > > > > I am going to post to nfsv4@ietf.org to see what they say. Please > > > > > let me know if Xin Li's patch resolves your problem, even though I > > > > > don't believe it is correct except for the UINT32_MAX case. Good > > > > > luck with it, rick > > > > and please keep us all in the loop as to what they say! > > > > > > > > the general N+2 bit sounds like bullshit to me.. its always N+1 in a > > > > number field that has a > > > > bit of slack at wrap time (probably due to some ambiguity in the > > > > original spec). > > > > > > > Actually, since N is the lock op already done, N + 1 is the next lock > > > operation in order. Since lock ops need to be strictly ordered, > allowing > > > N + 2 (which means N + 2 would be done before N + 1) makes no sense. > > > > > > I think the author of the RFC meant that N + 2 or greater fails, but it > > > was poorly worded. > > > > > > I will pass along whatever I get from nfsv4@ietf.org. (There is an > archive > > > of it somewhere, but I can't remember where.;-) > > > > > > rick > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > >