From owner-freebsd-fs@freebsd.org Thu Jul 2 23:21:21 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 87AD9993A5D for ; Thu, 2 Jul 2015 23:21:21 +0000 (UTC) (envelope-from email.ahmedkamal@googlemail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 15D9C1B0B; Thu, 2 Jul 2015 23:21:21 +0000 (UTC) (envelope-from email.ahmedkamal@googlemail.com) Received: by wguu7 with SMTP id u7so74978454wgu.3; Thu, 02 Jul 2015 16:21:19 -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=y2hFDBC3puKaXnVcqWs64+MbWLyNNV5ObTnVxpvIq14=; b=RhvV0MQF3f7wVD3MuRZB7dUlPFRfqyHaCu8//6Tvo/yjyU82WBpYkpc98IdkcRJeGk yJ4FcznLtr75ql7IoiH0yFLRpwSVMaO0JSOs0GcYuM9e5gOx8HldScxPw37Ps2jnCG6k epWvsfh9FRvfHGxVuwaqTyFdGnI0CwiQvaZ4aGraZ9l4957eWwrzUHwGMgfXJjEpKRdx nyBf6NHttlIGYPai9A9MvnIcPNvVZ5ZrAv0Ot9DmiQgPaw+clwTc7RxUcCi71zHLthkR g7BRI46aec267entF+05XZlTPBzud9O/Hr44eo6A5bDCxJ2Zqt4+v39aUmFIXoCADmPB KFjQ== X-Received: by 10.180.79.133 with SMTP id j5mr59233508wix.38.1435879279526; Thu, 02 Jul 2015 16:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.143 with HTTP; Thu, 2 Jul 2015 16:21:00 -0700 (PDT) In-Reply-To: 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:21:00 +0200 Message-ID: Subject: Re: Linux NFSv4 clients are getting (bad sequence-id error!) To: Rick Macklem Cc: Julian Elischer , freebsd-fs@freebsd.org, Xin LI 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:21:21 -0000 PS: Today (after adjusting tcp.highwater) I didn't get any screaming reports from users about hung vnc sessions. So maybe just maybe, linux clients are able to somehow recover from this bad sequence messages. I could still see the bad sequence error message in logs though Why isn't the highwater tunable set to something better by default ? I mean this server is certainly not under a high or unusual load (it's only 40 PCs mounting from it) On Fri, Jul 3, 2015 at 1:15 AM, Ahmed Kamal wrote: > 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" >> > > >> > >> > >