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 6EA8F41DDE9; Sat, 28 Feb 2026 17:45:50 +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=1772300750; cv=none; b=eI+XMKwXYexZmzyiRilx9/gQlmlQoF1Jodbz3gd8BR8Y8+9tR4DZYBxmt1fQRHHOvp2cvpv5A2OJ+TEPz3CwF3p2K/VXsUdCt2YdyzVF37e02Bdlbc0d2StUu77C5Pk0jYRlneGYmq7lv0Ov8PQMXxtZeRCr6zI08HPRel39I/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300750; c=relaxed/simple; bh=1HhwZmIlQJ5cO9vDpfo4RUmluN7cuB9Xo3xbXrzw4ho=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BlGqY2VTE9LT/AEDyLX71mlDnH+okF4Nx2xfXOu4PtfpRdoKZ8WWCL8aZdOfau1fYTa+dYe7mRaResUQnzaflpsDUlx/yve1XWDK0qrwvMVbejhb7KEjdyVpTuukUhNzrEX0zOCoMDOdZCeHf+n8V2GFqCBrXZWSQ4b38ssbrSo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LqSOqbJc; 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="LqSOqbJc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 982C4C19423; Sat, 28 Feb 2026 17:45:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300750; bh=1HhwZmIlQJ5cO9vDpfo4RUmluN7cuB9Xo3xbXrzw4ho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LqSOqbJctE2dgMXGh9pkKHh6L25NFkp+1OxyLo3fYbVlmblbo/OMgyV1sCMhrFJn3 hdkpK3jjn1OfeuBl7r8EKNAHIAMlQZnPkqJfwkgbmGTKDBWAxlkXbOxuXXRJzX3atm QM/FSg20FwUtfleB7HZEZswZDwstqaNz1jzrF9pwtN7dn7eN/zaJ34W/qF0jwJ0TVa wV+C6kRiHpSj/07sMvHU1oJOd7qe7NpKlGicABSSdjDf6CfAn5wAVzS7+sbLWaYL9L K3HyN1BNWKIL7sjU3WxQMAmpAJ4cy55YpkIoltVi2+1cPR4yjOa3FW5DlFZc7vV5fs 014XSL8tJbvkw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Edwards , Sam Edwards , Ilya Dryomov , Sasha Levin Subject: [PATCH 6.19 786/844] ceph: fix write storm on fscrypted files Date: Sat, 28 Feb 2026 12:31:39 -0500 Message-ID: <20260228173244.1509663-787-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit From: Sam Edwards [ Upstream commit cac190c7674fea71620d754ffcdaaeed7c551dbc ] CephFS stores file data across multiple RADOS objects. An object is the atomic unit of storage, so the writeback code must clean only folios that belong to the same object with each OSD request. CephFS also supports RAID0-style striping of file contents: if enabled, each object stores multiple unbroken "stripe units" covering different portions of the file; if disabled, a "stripe unit" is simply the whole object. The stripe unit is (usually) reported as the inode's block size. Though the writeback logic could, in principle, lock all dirty folios belonging to the same object, its current design is to lock only a single stripe unit at a time. Ever since this code was first written, it has determined this size by checking the inode's block size. However, the relatively-new fscrypt support needed to reduce the block size for encrypted inodes to the crypto block size (see 'fixes' commit), which causes an unnecessarily high number of write operations (~1024x as many, with 4MiB objects) and correspondingly degraded performance. Fix this (and clarify intent) by using i_layout.stripe_unit directly in ceph_define_write_size() so that encrypted inodes are written back with the same number of operations as if they were unencrypted. This patch depends on the preceding commit ("ceph: do not propagate page array emplacement errors as batch errors") for correctness. While it applies cleanly on its own, applying it alone will introduce a regression. This dependency is only relevant for kernels where ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") has been applied; stable kernels without that commit are unaffected. Cc: stable@vger.kernel.org Fixes: 94af0470924c ("ceph: add some fscrypt guardrails") Signed-off-by: Sam Edwards Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin --- fs/ceph/addr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 3cfe3df6e6a22..c6c853748942b 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1000,7 +1000,8 @@ unsigned int ceph_define_write_size(struct address_space *mapping) { struct inode *inode = mapping->host; struct ceph_fs_client *fsc = ceph_inode_to_fs_client(inode); - unsigned int wsize = i_blocksize(inode); + struct ceph_inode_info *ci = ceph_inode(inode); + unsigned int wsize = ci->i_layout.stripe_unit; if (fsc->mount_options->wsize < wsize) wsize = fsc->mount_options->wsize; -- 2.51.0