From mboxrd@z Thu Jan 1 00:00:00 1970 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 59339367 for ; Sun, 13 Jul 2025 17:50:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752429011; cv=none; b=C0JMdLZkrxQYVMvpeQ8VNzu6ERZdkpYEIF41/zJAYfEyPhs5Zq00/uY2GHEdrSj6g5xJoyo1PdZVAx9Rkn0/o6XNOznbT9iHc2chkfKeUhda/dhR7BIkDZ6pXiIQGcE0CvL3N1WxzE5AfNi1u4htgk1V+jpr5zGuWmsHev2b8S0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752429011; c=relaxed/simple; bh=0DGRPOSqsWlUkUCZlK9JlqHFgs14hd77qou2JOjTFnQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=upiwMgCi4qKofDmfjMiNv0/cB0rGVZkaN10qpI1BjcnrduYNBPWACnTnAOJ0Ci67j1UCx63nPHfZs/9CGVbURkmBfzTs6kPWmW7vJm8G4ABKbvMijStEog0ZBRmXrh9Cqtu9KQApePjdnmoWwwZU0Y91gzkbAX2WnhZiAmP1L3g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WT7Z/Xx7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WT7Z/Xx7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 425E6C4CEE3; Sun, 13 Jul 2025 17:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752429010; bh=0DGRPOSqsWlUkUCZlK9JlqHFgs14hd77qou2JOjTFnQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=WT7Z/Xx7bWvmM8q4OVtLwUr+QsrJxyvQpXKIy+Z67OeKSaKdMP8Y/Vr9MDWrSQbij dG58dJvNRGC0Yr+iUJqk5n5fIRASzTdzjsVHSt8CihLEGC4yWliDDnZ2QEd3ax6tXQ vlq/wbnxBNki4x4xbBqMY7Ql4o/ocRdEU/BW3Wb+gFn33pCXI+Mav3C8DWPE8flQVJ j4lb9rIM++OGuWKVd35JrUBbjM2mRHQIbL0fLk53kV+nBi+Md/J/2M9MZiuk3e6IgT G58UyTr5hZxPVJCq9MtqjvHa6rfgOg0WXF4nSa0jP4Y+vAhpWD8WaiScVW8SSVhKsD UyuYV1ODwKL7A== Message-ID: Date: Sun, 13 Jul 2025 13:50:09 -0400 Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] Revert "NFSD: Force all NFSv4.2 COPY requests to be synchronous" To: =?UTF-8?Q?Aur=C3=A9lien_Couderc?= Cc: NeilBrown , Jeff Layton , Olga Kornievskaia , Dai Ngo , Tom Talpey , linux-nfs@vger.kernel.org, Chuck Lever References: <20250618125803.1131150-1-cel@kernel.org> Content-Language: en-US From: Chuck Lever Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 7/12/25 9:06 AM, Aurélien Couderc wrote: > ? > > On Wed, Jun 18, 2025 at 9:22 PM Aurélien Couderc > wrote: >> >> On Wed, Jun 18, 2025 at 2:58 PM Chuck Lever wrote: >>> >>> From: Chuck Lever >>> >>> In the past several kernel releases, we've made NFSv4.2 async copy >>> reliable: >>> - The Linux NFS client and server now both implement and use the >>> NFSv4.2 OFFLOAD_STATUS operation >>> - The Linux NFS server keeps copy stateids around longer >>> - The Linux NFS client and server now both implement referring call >>> lists >>> >>> And resilient against DoS: >>> - The Linux NFS server limits the number of concurrent async copy >>> operations >> >> And how does an amin change that limit? There is zero documentation >> for admins, and zero training or reference material for COPY, CLONE, >> ALLOCATE, ... >> >> Aurélien >> -- >> Aurélien Couderc >> Big Data/Data mining expert, chess enthusiast > > > The tone of your original email suggested to me that it was a whine rather than a genuine request for more information. Also the request for "training material" for individual NFSv4.2 operations does not make sense. We do not have training material for the NFSv3 READDIRPLUS procedure, for example. Therefore I ignored the email. If you want reference material, the obvious place to look is the Internet standard that specifies these new operations (RFC 7862). It is publicly accessible on the web. If you need something more basic, I highly recommend Callaghan's "NFS Illustrated" (ISBN: 9780321618924). NFSv4.2 COPY, CLONE, and ALLOCATE are exposed to applications via the POSIX file system API available in Linux, as documented in man pages. There is no specific administrative setting that controls the number of concurrent asynchronous COPY operations. The limit increases with the number of NFSD threads. If someone demonstrates a specific use case where manually adjusting that limit is necessary, a setting can be implemented. The specific guidance you might be looking for is typically provided by the documentation staff at Linux distributions. You could file an issue with your favorite Linux vendor to let them know what you are looking for. -- Chuck Lever