Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp3055866rdd; Sat, 13 Jan 2024 13:14:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IGSpqldBvMGPFvxnbUXEXaIUuaFcdPxbmlRoiBxD/z4cfjL6CtvCj+EdN6lYlRiAFOTn5NX X-Received: by 2002:a92:d2d1:0:b0:360:a36d:ce59 with SMTP id w17-20020a92d2d1000000b00360a36dce59mr3907919ilg.13.1705180465184; Sat, 13 Jan 2024 13:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705180465; cv=none; d=google.com; s=arc-20160816; b=xc5yu5oVcP6r34vwENoUcoDppk3A6mefu9mGrDSzT/TO+g5rzYl4cdvI6E33VQ3gFH Ky0g44kxevLzjiUHW0ptDhqQ+hR6IwqUW4BJuNp9r1ctV42BrQZwY2aKgMU+9OFSsM61 gae+AOdH9IoXb8y3/kU4iwePFli9GzgXOBIsObRN+lPE8VfMMtTJ6ucARP12bvtCd49U tFLFAYlGIwYguF67SeC/+7mwEiqnCyPYwSmOfWNECEr11VeAytB0AQ1OrlhJC0F57eTa eihrL5mCBwb7eWYc6UpIOsI7ibC2F8ElggbLbPpRMWBpHUiDnyw4pKgvK5JQhvnEMJVm IgVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:content-transfer-encoding:autocrypt:references :in-reply-to:date:cc:to:from:subject:message-id:dkim-signature; bh=gNQn0TBi+NQI6quBq4+/Wh1b/2t2/bmL18krcbNi+hM=; fh=ywfGEGfb+qnJE1YeK2JNbJwiFM7+hfp/+oyzNNqWwvM=; b=Nsxm9aEKQN3ck/tCpWQ4FhetmD0pMzCXpUgcIfPxdSzlc+ddch4uq2ct8GhDkVzP+r +hDMnw5JCW4LzWYvhaZHfRhojqFS9m5KkHaTXuE+IN4cyQAyP7Zx+i7+2w6V87Mk3OMd VrpokHEb+oU5K9aTyqwXR8Cj3Cv9ttnLLa0bmZ2etbtQtwhiJ5woRrDGvt+RFdnfSbHP 58+7hdnsumiLVkSMTTlGfVpGuQzUxq2O2vCWafitZwV394NcurvrTPsDAVJAjlnoEwA1 wk5k7ZIGjdNyNUSbtP4FG8K14Par/ekwNwZIlktqQgwBbSuUJhqFN6wR5u1xnxy9nuQW JenQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WK1rxHFk; spf=pass (google.com: domain of linux-nfs+bounces-1078-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-1078-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id r2-20020a170903410200b001d0a0ee28e3si5754324pld.367.2024.01.13.13.14.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jan 2024 13:14:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs+bounces-1078-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WK1rxHFk; spf=pass (google.com: domain of linux-nfs+bounces-1078-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-1078-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 89DDD282127 for ; Sat, 13 Jan 2024 21:14:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 587C8107B2; Sat, 13 Jan 2024 21:14:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WK1rxHFk" X-Original-To: linux-nfs@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D38010797 for ; Sat, 13 Jan 2024 21:14:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 569DFC433C7; Sat, 13 Jan 2024 21:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705180462; bh=gNQn0TBi+NQI6quBq4+/Wh1b/2t2/bmL18krcbNi+hM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=WK1rxHFklT8QZPKrC/Qg0G3+ET07Xg7mbPXNhp9lzFR+kRBRT0rKsmBo/mg1ga0o+ Uo2n4uWBkz2+Eiul+tutAmOlRIqTHIUrNoQuFMHbjdctkrB0+KbH0H5tCW6Ithtjk1 o1cnDCCQDBAOJVWs4X874zCaaOKwDV6I/5ARJOU/Kiwmm+nDy73PGv+ZbUpEGv5/iC jKNbkQveKmb4oYjobnTNgpu3aXEZeZKo8t6nVYg7kloLDDTpuSQ5LopmQpy48Kxnis t2W+ebVNtjQOjMshi901W4oaGFuJ0paRxHk8YoK4p3XVPT1CLTDpBjgXoXD7a+aI+k FR9UjUXq1BLUQ== Message-ID: <3bd49c4ab5ace84ab39df7a0d2c8851542bfb9b9.camel@kernel.org> Subject: Re: kernel.org list issues... / was: Fwd: Turn NFSD_MAX_* into tuneables ? / was: Re: Increasing NFSD_MAX_OPS_PER_COMPOUND to 96 From: Jeff Layton To: Chuck Lever III , Roland Mainz Cc: Linux NFS Mailing List Date: Sat, 13 Jan 2024 16:14:21 -0500 In-Reply-To: <24ACA376-5239-4941-BE53-70BF5E5E4683@oracle.com> References: <65a29ca8.6b0a0220.ad415.d6d8.GMR@mx.google.com> <0cd8fbfc707f86784dc7d88653b05cd355f89aad.camel@kernel.org> <24ACA376-5239-4941-BE53-70BF5E5E4683@oracle.com> Autocrypt: addr=jlayton@kernel.org; prefer-encrypt=mutual; keydata=mQINBE6V0TwBEADXhJg7s8wFDwBMEvn0qyhAnzFLTOCHooMZyx7XO7dAiIhDSi7G1NPxwn8jdFUQMCR/GlpozMFlSFiZXiObE7sef9rTtM68ukUyZM4pJ9l0KjQNgDJ6Fr342Htkjxu/kFV1WvegyjnSsFt7EGoDjdKqr1TS9syJYFjagYtvWk/UfHlW09X+jOh4vYtfX7iYSx/NfqV3W1D7EDi0PqVT2h6v8i8YqsATFPwO4nuiTmL6I40ZofxVd+9wdRI4Db8yUNA4ZSP2nqLcLtFjClYRBoJvRWvsv4lm0OX6MYPtv76hka8lW4mnRmZqqx3UtfHX/hF/zH24Gj7A6sYKYLCU3YrI2Ogiu7/ksKcl7goQjpvtVYrOOI5VGLHge0awt7bhMCTM9KAfPc+xL/ZxAMVWd3NCk5SamL2cE99UWgtvNOIYU8m6EjTLhsj8snVluJH0/RcxEeFbnSaswVChNSGa7mXJrTR22lRL6ZPjdMgS2Km90haWPRc8Wolcz07Y2se0xpGVLEQcDEsvv5IMmeMe1/qLZ6NaVkNuL3WOXvxaVT9USW1+/SGipO2IpKJjeDZfehlB/kpfF24+RrK+seQfCBYyUE8QJpvTZyfUHNYldXlrjO6n5MdOempLqWpfOmcGkwnyNRBR46g/jf8KnPRwXs509yAqDB6sELZH+yWr9LQZEwARAQABtCVKZWZmIExheXRvbiA8amxheXRvbkBwb29jaGllcmVkcy5uZXQ+iQI7BBMBAgAlAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCTpXWPAIZAQAKCRAADmhBGVaCFc65D/4gBLNMHopQYgG/9RIM3kgFCCQV0pLv0hcg1cjr+bPI5f1PzJoOVi9s0wBDHwp8+vtHgYhM54yt43uI7Htij0RHFL5eFqoVT4TSfAg2qlvNemJEOY0e4daljjmZM7UtmpGs9NN0r9r50W82eb5Kw5bc/ r0kmR/arUS2st+ecRsCnwAOj6HiURwIgfDMHGPtSkoPpu3DDp/cjcYUg3HaOJuTjtGHFH963B+f+hyQ2BrQZBBE76ErgTDJ2Db9Ey0kw7VEZ4I2nnVUY9B5dE2pJFVO5HJBMp30fUGKvwaKqYCU2iAKxdmJXRIONb7dSde8LqZahuunPDMZyMA5+mkQl7kpIpR6kVDIiqmxzRuPeiMP7O2FCUlS2DnJnRVrHmCljLkZWf7ZUA22wJpepBligemtSRSbqCyZ3B48zJ8g5B8xLEntPo/NknSJaYRvfEQqGxgk5kkNWMIMDkfQOlDSXZvoxqU9wFH/9jTv1/6p8dHeGM0BsbBLMqQaqnWiVt5mG92E1zkOW69LnoozE6Le+12DsNW7RjiR5K+27MObjXEYIW7FIvNN/TQ6U1EOsdxwB8o//Yfc3p2QqPr5uS93SDDan5ehH59BnHpguTc27XiQQZ9EGiieCUx6Zh2ze3X2UW9YNzE15uKwkkuEIj60NvQRmEDfweYfOfPVOueC+iFifbQgSmVmZiBMYXl0b24gPGpsYXl0b25AcmVkaGF0LmNvbT6JAjgEEwECACIFAk6V0q0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAAOaEEZVoIViKUQALpvsacTMWWOd7SlPFzIYy2/fjvKlfB/Xs4YdNcf9qLqF+lk2RBUHdR/dGwZpvw/OLmnZ8TryDo2zXVJNWEEUFNc7wQpl3i78r6UU/GUY/RQmOgPhs3epQC3PMJj4xFx+VuVcf/MXgDDdBUHaCTT793hyBeDbQuciARDJAW24Q1RCmjcwWIV/pgrlFa4lAXsmhoac8UPc82Ijrs6ivlTweFf16VBc4nSLX5FB3ls7S5noRhm5/Zsd4PGPgIHgCZcPgkAnU1S/A/rSqf3FLpU+CbVBDvlVAnOq9gfNF+QiTlOHdZVIe4gEYAU3CUjbleywQqV02BKxPVM0C5/oVjMVx 3bri75n1TkBYGmqAXy9usCkHIsG5CBHmphv9MHmqMZQVsxvCzfnI5IO1+7MoloeeW/lxuyd0pU88dZsV/riHw87i2GJUJtVlMl5IGBNFpqoNUoqmvRfEMeXhy/kUX4Xc03I1coZIgmwLmCSXwx9MaCPFzV/dOOrju2xjO+2sYyB5BNtxRqUEyXglpujFZqJxxau7E0eXoYgoY9gtFGsspzFkVNntamVXEWVVgzJJr/EWW0y+jNd54MfPRqH+eCGuqlnNLktSAVz1MvVRY1dxUltSlDZT7P2bUoMorIPu8p7ZCg9dyX1+9T6Muc5dHxf/BBP/ir+3e8JTFQBFOiLNdFtB9KZWZmIExheXRvbiA8amxheXRvbkBzYW1iYS5vcmc+iQI4BBMBAgAiBQJOldK9AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAADmhBGVaCFWgWD/0ZRi4hN9FK2BdQs9RwNnFZUr7JidAWfCrs37XrA/56olQl3ojn0fQtrP4DbTmCuh0SfMijB24psy1GnkPepnaQ6VRf7Dxg/Y8muZELSOtsv2CKt3/02J1BBitrkkqmHyni5fLLYYg6fub0T/8Kwo1qGPdu1hx2BQRERYtQ/S5d/T0cACdlzi6w8rs5f09hU9Tu4qV1JLKmBTgUWKN969HPRkxiojLQziHVyM/weR5Reu6FZVNuVBGqBD+sfk/c98VJHjsQhYJijcsmgMb1NohAzwrBKcSGKOWJToGEO/1RkIN8tqGnYNp2G+aR685D0chgTl1WzPRM6mFG1+n2b2RR95DxumKVpwBwdLPoCkI24JkeDJ7lXSe3uFWISstFGt0HL8EewP8RuGC8s5h7Ct91HMNQTbjgA+Vi1foWUVXpEintAKgoywaIDlJfTZIl6Ew8ETN/7DLy8bXYgq0XzhaKg3CnOUuGQV5/nl4OAX/3jocT5Cz/OtAiNYj5mLPeL5z2ZszjoCAH6caqsF2oLyA nLqRgDgR+wTQT6gMhr2IRsl+cp8gPHBwQ4uZMb+X00c/Amm9VfviT+BI7B66cnC7Zv6Gvmtu2rEjWDGWPqUgccB7hdMKnKDthkA227/82tYoFiFMb/NwtgGrn5n2vwJyKN6SEoygGrNt0SI84y6hEVbQlSmVmZiBMYXl0b24gPGpsYXl0b25AcHJpbWFyeWRhdGEuY29tPokCOQQTAQIAIwUCU4xmKQIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEAAOaEEZVoIV1H0P/j4OUTwFd7BBbpoSp695qb6HqCzWMuExsp8nZjruymMaeZbGr3OWMNEXRI1FWNHMtcMHWLP/RaDqCJil28proO+PQ/yPhsr2QqJcW4nr91tBrv/MqItuAXLYlsgXqp4BxLP67bzRJ1Bd2x0bWXurpEXY//VBOLnODqThGEcL7jouwjmnRh9FTKZfBDpFRaEfDFOXIfAkMKBa/c9TQwRpx2DPsl3eFWVCNuNGKeGsirLqCxUg5kWTxEorROppz9oU4HPicL6rRH22Ce6nOAON2vHvhkUuO3GbffhrcsPD4DaYup4ic+DxWm+DaSSRJ+e1yJvwi6NmQ9P9UAuLG93S2MdNNbosZ9P8k2mTOVKMc+GooI9Ve/vH8unwitwo7ORMVXhJeU6Q0X7zf3SjwDq2lBhn1DSuTsn2DbsNTiDvqrAaCvbsTsw+SZRwF85eG67eAwouYk+dnKmp1q57LDKMyzysij2oDKbcBlwB/TeX16p8+LxECv51asjS9TInnipssssUDrHIvoTTXWcz7Y5wIngxDFwT8rPY3EggzLGfK5Zx2Q5S/N0FfmADmKknG/D8qGIcJE574D956tiUDKN4I+/g125ORR1v7bP+OIaayAvq17RP+qcAqkxc0x8iCYVCYDouDyNvWPGRhbLUO7mlBpjW9jK9e2fvZY9iw3QzIPGKtClKZWZmIExheXRvbiA8amVmZi5sYXl0 b25AcHJpbWFyeWRhdGEuY29tPokCOQQTAQIAIwUCU4xmUAIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEAAOaEEZVoIVzJoQALFCS6n/FHQS+hIzHIb56JbokhK0AFqoLVzLKzrnaeXhE5isWcVg0eoV2oTScIwUSUapy94if69tnUo4Q7YNt8/6yFM6hwZAxFjOXR0ciGE3Q+Z1zi49Ox51yjGMQGxlakV9ep4sV/d5a50M+LFTmYSAFp6HY23JN9PkjVJC4PUv5DYRbOZ6Y1+TfXKBAewMVqtwT1Y+LPlfmI8dbbbuUX/kKZ5ddhV2736fgyfpslvJKYl0YifUOVy4D1G/oSycyHkJG78OvX4JKcf2kKzVvg7/Rnv+AueCfFQ6nGwPn0P91I7TEOC4XfZ6a1K3uTp4fPPs1Wn75X7K8lzJP/p8lme40uqwAyBjk+IA5VGd+CVRiyJTpGZwA0jwSYLyXboX+Dqm9pSYzmC9+/AE7lIgpWj+3iNisp1SWtHc4pdtQ5EU2SEz8yKvDbD0lNDbv4ljI7eflPsvN6vOrxz24mCliEco5DwhpaaSnzWnbAPXhQDWb/lUgs/JNk8dtwmvWnqCwRqElMLVisAbJmC0BhZ/Ab4sph3EaiZfdXKhiQqSGdK4La3OTJOJYZphPdGgnkvDV9Pl1QZ0ijXQrVIy3zd6VCNaKYq7BAKidn5g/2Q8oio9Tf4XfdZ9dtwcB+bwDJFgvvDYaZ5bI3ln4V3EyW5i2NfXazz/GA/I/ZtbsigCFc8ftCBKZWZmIExheXRvbiA8amxheXRvbkBrZXJuZWwub3JnPokCOAQTAQIAIgUCWe8u6AIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQAA5oQRlWghUuCg/+Lb/xGxZD2Q1oJVAE37uW308UpVSD2tAMJUvFTdDbfe3zKlPDTuVsyNsALBGclPLagJ5ZTP+Vp2irAN9uwBuac BOTtmOdz4ZN2tdvNgozzuxp4CHBDVzAslUi2idy+xpsp47DWPxYFIRP3M8QG/aNW052LaPc0cedYxp8+9eiVUNpxF4SiU4i9JDfX/sn9XcfoVZIxMpCRE750zvJvcCUz9HojsrMQ1NFc7MFT1z3MOW2/RlzPcog7xvR5ENPH19ojRDCHqumUHRry+RF0lH00clzX/W8OrQJZtoBPXv9ahka/Vp7kEulcBJr1cH5Wz/WprhsIM7U9pse1f1gYy9YbXtWctUz8uvDR7shsQxAhX3qO7DilMtuGo1v97I/Kx4gXQ52syh/w6EBny71CZrOgD6kJwPVVAaM1LRC28muq91WCFhs/nzHozpbzcheyGtMUI2Ao4K6mnY+3zIuXPygZMFr9KXE6fF7HzKxKuZMJOaEZCiDOq0anx6FmOzs5E6Jqdpo/mtI8beK+BE7Va6ni7YrQlnT0i3vaTVMTiCThbqsB20VrbMjlhpf8lfK1XVNbRq/R7GZ9zHESlsa35ha60yd/j3pu5hT2xyy8krV8vGhHvnJ1XRMJBAB/UYb6FyC7S+mQZIQXVeAA+smfTT0tDrisj1U5x6ZB9b3nBg65ke5Ag0ETpXRPAEQAJkVmzCmF+IEenf9a2nZRXMluJohnfl2wCMmw5qNzyk0f+mYuTwTCpw7BE2H0yXk4ZfAuA+xdj14K0A1Dj52j/fKRuDqoNAhQe0b6ipo85Sz98G+XnmQOMeFVp5G1Z7r/QP/nus3mXvtFsu9lLSjMA0cam2NLDt7vx3l9kUYlQBhyIE7/DkKg+3fdqRg7qJoMHNcODtQY+n3hMyaVpplJ/l0DdQDbRSZi5AzDM3DWZEShhuP6/E2LN4O3xWnZukEiz688d1ppl7vBZO9wBql6Ft9Og74diZrTN6lXGGjEWRvO55h6ijMsLCLNDRAVehPhZvSlPldtUuvhZLAjdWpwmzbRIwgoQcO51aWeKthpcpj8feDdKdlVjvJO9fgFD5kqZ QiErRVPpB7VzA/pYV5Mdy7GMbPjmO0IpoL0tVZ8JvUzUZXB3ErS/dJflvboAAQeLpLCkQjqZiQ/DCmgJCrBJst9Xc7YsKKS379Tc3GU33HNSpaOxs2NwfzoesyjKU+P35czvXWTtj7KVVSj3SgzzFk+gLx8y2Nvt9iESdZ1Ustv8tipDsGcvIZ43MQwqU9YbLg8k4V9ch+Mo8SE+C0jyZYDCE2ZGf3OztvtSYMsTnF6/luzVyej1AFVYjKHORzNoTwdHUeC+9/07GO0bMYTPXYvJ/vxBFm3oniXyhgb5FtABEBAAGJAh8EGAECAAkFAk6V0TwCGwwACgkQAA5oQRlWghXhZRAAyycZ2DDyXh2bMYvI8uHgCbeXfL3QCvcw2XoZTH2l2umPiTzrCsDJhgwZfG9BDyOHaYhPasd5qgrUBtjjUiNKjVM+Cx1DnieR0dZWafnqGv682avPblfi70XXr2juRE/fSZoZkyZhm+nsLuIcXTnzY4D572JGrpRMTpNpGmitBdh1l/9O7Fb64uLOtA5Qj5jcHHOjL0DZpjmFWYKlSAHmURHrE8M0qRryQXvlhoQxlJR4nvQrjOPMsqWD5F9mcRyowOzr8amasLv43w92rD2nHoBK6rbFE/qC7AAjABEsZq8+TQmueN0maIXUQu7TBzejsEbV0i29z+kkrjU2NmK5pcxgAtehVxpZJ14LqmN6E0suTtzjNT1eMoqOPrMSx+6vOCIuvJ/MVYnQgHhjtPPnU86mebTY5Loy9YfJAC2EVpxtcCbx2KiwErTndEyWL+GL53LuScUD7tW8vYbGIp4RlnUgPLbqpgssq2gwYO9m75FGuKuB2+2bCGajqalid5nzeq9v7cYLLRgArJfOIBWZrHy2m0C+pFu9DSuV6SNr2dvMQUv1V58h0FaSOxHVQnJdnoHn13g/CKKvyg2EMrMt/EfcXgvDwQbnG9we4xJiWOIOcsvrWcB6C6lWBDA+In7w7SXnnok kZWuOsJdJQdmwlWC5L5ln9xgfr/4mOY38B0U= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 (3.50.2-1.fc39) Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2024-01-13 at 16:10 +0000, Chuck Lever III wrote: >=20 > > On Jan 13, 2024, at 10:09=E2=80=AFAM, Jeff Layton = wrote: > >=20 > > On Sat, 2024-01-13 at 15:47 +0100, Roland Mainz wrote: > > >=20 > > > On Sat, Jan 13, 2024 at 1:19=E2=80=AFAM Dan Shelton wrote: > > > > We've been experiencing significant nfsd performance problems with = a > > > > customer who has a deeply nested filesystem hierarchy, lots of > > > > subdirs, some of them 60-80 dirs deep (!!), which leads to an > > > > exponentially slowdown with nfsd accesses. > > > >=20 > > > > Some of the issues have been addressed by implementing a better > > > > directory walker via multiple dir fds and openat() (instead of just > > > > cwd+open()), but the nfsd side still was a pretty dramatic issue, > > > > until we bumped #define NFSD_MAX_OPS_PER_COMPOUND in > > > > linux-6.7/fs/nfsd/nfsd.h from 50 to 96. After that the nfsd side > > > > behaved MUCH more performant. > > >=20 > > > More general question: > > > Is it feasible to turn the values for NFSD_MAX_* (max_ops, > > > max_req etc., e.g. everything which is being negotiated in a NFSv4.1 > > > session) into tuneables, which are set at nfsd startup ? It might hel= p > > > with Dan's scenario, benchmarking, client testing (e.g. my case, wher= e > > > I switched to nfs4j) and tuning... > > >=20 > >=20 > > (re-cc'ing the mailing list...) > >=20 > > We generally don't like to add knobs like this when we can get by with > > just tuning a sane value for everyone. This particular value governs th= e > > maximum number of operations per compound. I don't see any value in > > keeping it artificially low. > >=20 > > The only real argument against it that I can see is that it might make > > it easier for a malicious or badly-designed client to DoS the server. > > That's certainly something we should be wary of, but I don't expect tha= t > > increasing the max from 50 to ~100 will make a big difference there. >=20 > The server allocates memory and other resources based on the > largest COMPOUND it expects. >=20 > If we crank the maximum number, it has an impact on server > resource utilization. In particular, those extra COMPOUND > slots will almost never be used except in a handful of corner > cases. >=20 > Plus, this becomes a race against applications and workloads > that try to consume past that limit. We bump it, they use > more and hit the new limit. We bump it, lather, rinse, > repeat. >=20 > Indeed, if we increase that value enough, it does become a > server DoS vector by tying up all available nfsd threads > trying to execute enormous COMPOUNDs. >=20 > Upshot is I'm not in favor of increasing the max-ops limit or > making it tunable, unless we have grossly misunderstood the > issue. >=20 Does it? The only thing that I could see that scales directly with that value is the size of struct nfsd_genl_rqstp. That's just part of the new netlink stats interface, so I don't see that as a show stopper. Am I missing something else that scales directly with NFSD_MAX_OPS_PER_COMPOUND? >=20 > > > Solaris 11 is known to send COMPOUNDs that are too large > > > during mount, but the rest of the time these three client > > > implementations are not known to send large COMPOUNDs. > > Actually the FreeBSD client is the same as Solaris, in that it does the > > entire mount path in one compound. If you were to attempt a mount > > with more than 48 components, it would exceed 50 ops in the compound. > > I don't think it can exceed 50 ops any other way. >=20 >=20 > I'd like to see the raw packet captures to confirm that our > speculation about the problem is indeed correct. Since this > limit is hit only when mounting (and not at all by Linux > clients), I don't yet see how that would "make NFSD slow". >=20 It seems quite plausible that keeping the max low causes the client to have to do a deep pathwalk using multiple RPCs instead of one. That seems like it could have performance implications. > > > I guess your clients are trying to do a long pathwalk in a single > > > COMPOUND? > >=20 > > Is there a problem with that (assuming NFSv4.1 session limits are honor= ed) ? >=20 > Yes: very clearly the client will hit a rather artificial > path length limit. And the limit isn't based on the character > length of the path: the limit is hit much sooner with a path > that is constructed from a series of very short component > names, for instance. >=20 > Good client implementations keep the number of operations per > COMPOUND limited to a small number, and break up operations > like path walks to ensure that the protocol and server > implementation do not impose any kind of application-visible > constraint. >=20 >=20 Sure, and good servers try their best to deal with whatever the clients throw at them. I don't really see the value in limiting the number of ops per compound. Are we really any better off having the client break those up into multiple round trips? Why? --=20 Jeff Layton