From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEB9DC5AD49 for ; Mon, 9 Jun 2025 04:01:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 749E16B007B; Mon, 9 Jun 2025 00:01:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7220E6B0088; Mon, 9 Jun 2025 00:01:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6385D6B0089; Mon, 9 Jun 2025 00:01:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 498016B007B for ; Mon, 9 Jun 2025 00:01:06 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E0889BE382 for ; Mon, 9 Jun 2025 04:01:05 +0000 (UTC) X-FDA: 83534511690.22.9D78B78 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf16.hostedemail.com (Postfix) with ESMTP id EA64E18000C for ; Mon, 9 Jun 2025 04:01:03 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf16.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749441664; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+OrUcEIJpkzIqPSaSMapcl8mkrvVwMc4GV6bBX9ZsrI=; b=knmkYOCzIFs/n2P/VDNYG7+6RO/EKNj6OkRQU+nmk934rJ0KShXBZko9Yn+jzxp6Vss8B0 bHB/1b+KQKjhYVUl477C95yrYURBJBptijFFLjQ8QgUVxblLj1QgmprU3rkVjKQuuhejSf 0abc3aT1Na5BooypVPrcH5idUx93d0U= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=lst.de; spf=pass (imf16.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749441664; a=rsa-sha256; cv=none; b=nXdaU/Tklv2e5u2wv0cBLIAkrSq/Se51oNWU2BM8NdUmqvMIptJAMLoruwc3dlJXW/KzXa wVlcrHLHT5MlAq3s6igIx0a7vqCfchEOP+o796Sq3ifGM4Mr0aodsT5WRo+Oe9SUz4/SIf tCBA4kAAKcqhTjm0lVyJSsBNFJpm/Jo= Received: by verein.lst.de (Postfix, from userid 2407) id 4222168AFE; Mon, 9 Jun 2025 06:00:57 +0200 (CEST) Date: Mon, 9 Jun 2025 06:00:56 +0200 From: Christoph Hellwig To: Kundan Kumar Cc: Christoph Hellwig , Anuj gupta , Anuj Gupta/Anuj Gupta , Kundan Kumar , jaegeuk@kernel.org, chao@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, miklos@szeredi.hu, agruenba@redhat.com, trondmy@kernel.org, anna@kernel.org, akpm@linux-foundation.org, willy@infradead.org, mcgrof@kernel.org, clm@meta.com, david@fromorbit.com, amir73il@gmail.com, axboe@kernel.dk, ritesh.list@gmail.com, djwong@kernel.org, dave@stgolabs.net, p.raghav@samsung.com, da.gomez@samsung.com, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, gfs2@lists.linux.dev, linux-nfs@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com Subject: Re: [PATCH 00/13] Parallelizing filesystem writeback Message-ID: <20250609040056.GA26101@lst.de> References: <20250529111504.89912-1-kundan.kumar@samsung.com> <20250602141904.GA21996@lst.de> <20250603132434.GA10865@lst.de> <20250603140445.GA14351@lst.de> <20250603140513.GB14351@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: EA64E18000C X-Stat-Signature: 997zy7kpnxsx8mcoeuaucasq7yitfme3 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1749441663-279581 X-HE-Meta: U2FsdGVkX1/q/HXQocp9SqEUD4l7x1xjvWY3JL4QiuuiRM+VlWehIxTFrjiRGqZ0UYp8Fh3wY+Tp/D4Sl27+ZiCeGa9Zewc0Ot2a0Ae3lR7oZzqSV92TRqKgPk2iuF1Kj7vIuNntAhlA801cIPdjnejoETK1xbcTiLHxz+ETlYR5cqpMV9PLq1XXCWH/RVzfwi54z3PY1URwd3Jau7lFn0FI7XwBMJXllsrDhvFGtYuBP1FbS3TGB8vUKjlJuRIviodkjqNbQXdlKTQR2kwE+WevIaUM/++FfqAroV7RFoyWWvz7RB+9VsTQx2UvIaem/Led/AeEgGykpXHaFlWti6K7K4bLGfMq/hJEG06DyjkunfmmWrqvbabqhpLmG+jdlQLGPGy2vLL2BobJzTFmJj2pgbbE0859L+5s/FmhXwQy8PgrsjG7PLRJH/6015gTWRN8zou+5FgGg7QfKxGs5R24I8Lv0trSF+sGHXbUrwoyuhkYD6PaK42HREHLyetdd8l5G1ipjsOblBFk7Ff/g0ue4vaQUWt2D+/YiwpdyGsLhEa1WbihjY6de2LVYeWYJchMFUjcQov2arDOaJLVtgjDwIs48jsdhSLLinGG6lRjvfBLDYh6yqNjZd4BZsHO5IWSwoOmCnBlRoxRrW53MplfF4kSsePPtUNomDWgL4vg4FC3BAgtA2gy0qP2Qq2DSbLZbTEl6iPJRh/kMCUyGvbhqQFXHX1kLoIW3dlFMcbfNguZQLcAqRVlSwporUdB4S+dmVOx4hOdsxw3GuJkCHAVaruSbEkHHp3auiMrbtHbvVKxvonWzIrm00bnN9d7Y3dCbL40B/BoaCTGVrPNeub2shv0NTva9/Fv/GWKxSnVl8W5J/thGDkEBByMfYpo/IFSLM8zqjApX4mzkLOdlLKZP2YN2DY0JngvOvLIiiWNoxXHSNDiELYY8RFyEEFEzk5TnLcd/SHmshQ1nKd iFl/ogBg /ehMK5o1XYuyPAI+FDt7aEoPedEly+BiiPOeEY8FoeL0MzJukW+AUX+z7CMk91/csAwD4Nt3i4Cpx5JgQPzvcDR77qchNmNfz7j8KYMwPTlGw7Lh8UbDEWro61kTwud2Tt2jEkTLAtFahEmUgwCuArB34MQyXHaC5F40A5eF5KbRTJ7WKmgNwNtPrEKmZMxXCDuIr X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 06, 2025 at 10:34:42AM +0530, Kundan Kumar wrote: > Thanks for the suggestion β€” I agree the default should come from a > filesystem-level helper, not a mount option. > > I looked into the sysfs override idea, but one challenge is that > nr_wb_ctx must be finalized before any writes occur. That leaves only > a narrow window β€” after the bdi is registered but before any inodes > are dirtied β€” where changing it is safe. > > This makes the sysfs knob a bit fragile unless we tightly guard it > (e.g., mark it read-only after init). A mount option, even just as an > override, feels simpler and more predictable, since it’s set before > the FS becomes active. The mount option has a few issues: - the common VFS code only support flags, not value options, so you'd have to wire this up in every file system - some file system might not want to allow changing it - changing it at runtime is actuallyt quite useful So you'll need to quiesce writeback or maybe even do a full fs freeze when changing it a runtime, but that seems ok for a change this invasive.