From nobody Sat Feb 7 08:42:47 2026 Received: from mail-dl1-f43.google.com (mail-dl1-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 165A0299A90 for ; Mon, 26 Jan 2026 02:31:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394670; cv=none; b=V4ApQZhqaRAmKf79a7+qYg2R6Fpbecxftkpxftg8Rc6C6LIuhUTGuL9WAdL9JyJUpFQLaf8SFGK8hVlT5DiywF46XAioRX7+Vzta6dnyXHUkG95Qs+GdKMi81ddbUbhGbt7/VI7Mz2CwoOL4EoGSUaDN3zIJGnT7z8UyI1ZbRNo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394670; c=relaxed/simple; bh=xreigetpjHdKa6OZ71uh6zOcPjuDFrwATx0og6exOHo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NKhPCp3XVskoAY7c1GBmt2WkwLc25VvG+JGkcIdoqaALuB8StikEYRAfIyInwmLm1nnxZ/bzyR5iV0hAaWWq9gita5xw4Yv3IhnpFwNW+VInkHoj+lLq1sR3J7xuHxfU9DOrG8afTrZp7GnrMpMRv6kkSwie4yKyCsQDiIAyLBc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a5sQpun3; arc=none smtp.client-ip=74.125.82.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a5sQpun3" Received: by mail-dl1-f43.google.com with SMTP id a92af1059eb24-1233b172f02so5691861c88.0 for ; Sun, 25 Jan 2026 18:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769394668; x=1769999468; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7OeqEToDWh87NKXAJBkWa10HlZtuXDj/TYqt7IVavaQ=; b=a5sQpun34domUif7GnfgZYl25NskFflCpMYZekv2FE2b3UNFQ4ca3mDL5YQP2bydJn kLFIsU5x7RKY0qNA7WxGTaZTfCmihrhBOdW2uAVR4ZlHZfMrZDqhDi5gRZ0EOjw7N9Ub kKD4UbMTvpzdVMFMlWwVD7zAbxnCjQrhSAAVQKjJPyPAHxtqTTjaNgUWaAOzYAUBd6p0 h2VgjQbGGjmZgjYh4zKp1zbohqaB32CrsMMJC0MT6E3ebMiMybed73hcnyshhvFdsHeB vuHk7m9RFow6+pWpimROCROmWP9k7Jw/Rfhb4SEHmx1g691eb3P7Wi26tRBoVmrmpkS/ DpXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769394668; x=1769999468; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7OeqEToDWh87NKXAJBkWa10HlZtuXDj/TYqt7IVavaQ=; b=W2c+s0NmIKa/IYmMVOS7LDe2FwmDHAdqrS3wLJzzNGI9nci39V1yD+JpCPEG1jks5Z rEPICjDYEGFbrv44Zt6oj2zdaANmLfzqKxBYTEsaKkn4FQLGtTnwb4weDBG0qPglZ49g qHe0fMXxaNAWdr/8qG0Eci3TbF3kGEPt10KAWbhiYu6aQSfJkBWtbmbmEIFPlg8mkh5x i7w6gtx3yZ1LV4uzV1DOSCAlTXEVHga+69wl1DoIhoGKoIUP7+7eRPCxgS2e7U27iLll IqG02a5ZzMd54P2tYWxjTt+ec5HDhbst1C3uSG8HJAhIF8DOLY1WHM/689p6MGdvvIel cASw== X-Forwarded-Encrypted: i=1; AJvYcCVCq17LHjtQZ8apurXpix0XkE7hX130QE5faknhnXiIqAslj/flZznz1Y2mWCvZT+Y6D+LOyVkdM9ZEyjQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2rWCyL0Zm2MGtR4JRLSfiHGWl11k2/k+uJfm/aGRt+yV2REUr 7wOkrMRVkM3NOhyvkzE8gpgxN6eJaTXZ8+FWfM/P03nk26VwVUzlAce1 X-Gm-Gg: AZuq6aIak2t0S4TqtFrDf0JuOjhPeV7TI1XtLhN9K3/Q/9h7nKQw+bJI72qsONYv6kg 3L76x48eYVlgvJfAZDvUMswHhxx9rvgTVAjiK8QQL3+ofb7BPoGyYn6Vs6ImykcumLCsf4HLguk wd7pnhLGH+RAPjgRW4Q0TtvWVvrmn2BhOGOLCu6d95gzKX15LM6GCVChRzlokFe9WQPQ+YfTlDL gf7BTl1pTyNTAuwRX43xl2rSVEV6tcHkR8RUhGmKus2EjWyEF3gI34FFUVP7MnbTX7GF6B3Hbh+ OztjlnPeqOd2jrPiAAtZwqsQl10Ciz+ZUoTy8MbBk5zSSHu4C8YMuthI3Vt9ah20NJu8SFYHOkE 3XSOB1YUZG6bPGVyA4HRX16t+8bZetLyjov2h/dKAZclCpYnj5FVQEIZQvA4prEt9OjH9rogDEE 4G7CPd82KTJu4WkV4A4VhDin4rm29oebeExh9yKKP4QfrVtugrec1g X-Received: by 2002:a05:7022:238d:b0:119:e56b:98a1 with SMTP id a92af1059eb24-1248ebe99acmr1414133c88.8.1769394668050; Sun, 25 Jan 2026 18:31:08 -0800 (PST) Received: from luna.turtle.lan (static-23-234-93-211.cust.tzulo.com. [23.234.93.211]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1247d91c52bsm17212277c88.6.2026.01.25.18.31.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 18:31:07 -0800 (PST) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Xiubo Li , Ilya Dryomov Cc: Viacheslav Dubeyko , Christian Brauner , Milind Changire , Jeff Layton , ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org, Sam Edwards , stable@vger.kernel.org Subject: [PATCH v3 2/4] ceph: fix write storm on fscrypted files Date: Sun, 25 Jan 2026 18:30:53 -0800 Message-ID: <20260126023055.405401-3-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260126023055.405401-1-CFSworks@gmail.com> References: <20260126023055.405401-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. Fixes: 94af0470924c ("ceph: add some fscrypt guardrails") Cc: stable@vger.kernel.org Signed-off-by: Sam Edwards --- 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 3462df35d245..39064893f35b 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1000,7 +1000,8 @@ unsigned int ceph_define_write_size(struct address_sp= ace *mapping) { struct inode *inode =3D mapping->host; struct ceph_fs_client *fsc =3D ceph_inode_to_fs_client(inode); - unsigned int wsize =3D i_blocksize(inode); + struct ceph_inode_info *ci =3D ceph_inode(inode); + unsigned int wsize =3D ci->i_layout.stripe_unit; =20 if (fsc->mount_options->wsize < wsize) wsize =3D fsc->mount_options->wsize; --=20 2.52.0