Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2503178ybn; Thu, 26 Sep 2019 12:56:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxCy2oJeGEgPMIxPtmw/N+z4qGWftiv8zX+VN9HeueTwLy7dQlUNRV6nFxhUscDhcSuw8e1 X-Received: by 2002:a17:906:e297:: with SMTP id gg23mr4679861ejb.47.1569527791644; Thu, 26 Sep 2019 12:56:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569527791; cv=none; d=google.com; s=arc-20160816; b=jOEMIqpS8sRlwaPISjmgUnn5Qa40bKioo4LHATsABZN9RD6O8hGjqISIjoQYakfVzu 1YrSL7tlttEp3tH/52vSIXrQ9fqUAuE0p7LeUNK6SGCp7738WNGIlavCzbzgxNb2y5+9 i1gQdp+vlr6eldGaJc0UsZAMJrL/7dlr+dqiaAGpHpaJ89FdlJLX/jQ2iC+8ed9mhx3A jXl7cpjd3j5Rq9H7ZYv9PSLrtLrm+bzEa3yl2pH7Ur1Y24NXD1fQJxUK6ZyKrjx87eQP gN0xtAZOO9+4StncKxgmxv7VUnPaeJBF97RN/jWXkA6eZvYrcRlO/AOH1pR6R0HRuJiw PANw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=MJO5EG3sINgdjBqn4V7Tl7HLNi+nHild6HahNzulUaE=; b=v35SFpl+kVnomtLxLyn4w5n2cgNuPwDLnnwVwMVuJtPSrC3smhEKklUYVaS7+pEuGo ywxKyZl6y4BtUUylhtsaZ6um2MLJ0JJbJLWeGi0ird2w0oErkt7etLRBmRCIzXVJ9sHB f/2deUC+Xf/DK89n0kcFoYsDsaZzwghm1TZwAgSs6sX/S5W+KoET32lk9U81ev16dzsG U1VjvIUcXaqqqME0mZikCP5/Uurwj0ajJe98xRQA99g27IHLNobBr0/GEx71Ww3vrtcR iJU4MrrmZrux+jfopjl1CLt3NsaEHtrELYFKPR9ME9cmr89bo+9SGrkB+ff59uySGcBC l4WQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y10si1619398eje.50.2019.09.26.12.56.05; Thu, 26 Sep 2019 12:56:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727988AbfIZTz5 (ORCPT + 99 others); Thu, 26 Sep 2019 15:55:57 -0400 Received: from fieldses.org ([173.255.197.46]:60856 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727794AbfIZTz5 (ORCPT ); Thu, 26 Sep 2019 15:55:57 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 5847B1507; Thu, 26 Sep 2019 15:55:57 -0400 (EDT) Date: Thu, 26 Sep 2019 15:55:57 -0400 From: Bruce Fields To: Chuck Lever Cc: Trond Myklebust , Kevin Vasko , Linux NFS Mailing List Subject: Re: NFSv4 client locks up on larger writes with Kerberos enabled Message-ID: <20190926195557.GC2849@fieldses.org> References: <20190925164831.GA9366@fieldses.org> <57192382-86BE-4878-9AE0-B22833D56367@oracle.com> <20190925200723.GA11954@fieldses.org> <1BC54D7A-073E-40FD-9AA3-552F1E1BD214@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BC54D7A-073E-40FD-9AA3-552F1E1BD214@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Sep 26, 2019 at 08:55:17AM -0700, Chuck Lever wrote: > > On Sep 25, 2019, at 1:07 PM, Bruce Fields wrote: > > In that case--I seem to remember there's a way to configure the size of > > the client's slot table, maybe lowering that (decreasing the number of > > rpc's allowed to be outstanding at a time) would work around the > > problem. > > > Should the client be doing something different to avoid or recover from > > overflows of the gss window? > > The client attempts to meter the request stream so that it stays > within the bounds of the GSS sequence number window. The stream > of requests is typically unordered coming out of the transmit > queue. > > There is some new code (since maybe v5.0?) that handles the > metering: gss_xmit_need_reencode(). I guess I was thinking he could write a small number (say 2 digits) into /sys/module/sunrpc/parameters/tcp_max_slot_table_entries (before mounting, I guess?) and see if the problem's reproducable. If not, that's a little more evidence that it's the gss sequence window. (And might be an adequate workaround for now.) --b.