From nobody Sat Feb 7 11:31:35 2026 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 57F5E2E7F20 for ; Wed, 31 Dec 2025 02:55:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767149735; cv=none; b=lU+wJ3R+gOf+C3c4ZxjVQbZy1zXHeJoYw+LPfm4jQn4ciHd/KlFGhtE+bCJya1Pl5RUUuJkXhQAYKXvXzYOIbv2HujfH6sp1jX4AtCZqQvmE8sVugl2gTpw21KlSfoopz+pjBb8z2uWvPakjC7cp9SuUah1i8axWBTHbnCPYjZU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767149735; c=relaxed/simple; bh=ZDstEKMD7WmKxZZCLmwJ/YSTgZ+JJejC8hgxByR/0Qk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=COX3HIqTgMZLrweHimaYQz+KLLvVlqIQvJcuhXf/hd/kiBgSCSNBuxgTthWcBwEXKByFXsKIO1yCmjH0cgxcSwz1NHGYAdgOkRX22tI6rBYjtSRf/A6s/1b0RnzijYhmJjx65bfXLYI05OLZ5gpOrKtaFx3Q8KtrbyfzoCwbkKU= 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=c09rU1ii; arc=none smtp.client-ip=209.85.210.174 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="c09rU1ii" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-7f651586be1so4991814b3a.1 for ; Tue, 30 Dec 2025 18:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767149733; x=1767754533; 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=mHQgO64N0mSOshA8/jcIaTzSFR+k9jE4B9vdvYmYNSA=; b=c09rU1iiRIUXGYCG+xJjTF/72ONz3lxVQWa1Cu5JmKGKTpNKxS05RLVd4/BbA/mZg8 rWJdzmu3QGd5Nq5UMThcVlBk+/ES9d3U2ffpjcmBezEqXt4fUYApXh9hshsgC+R+yURd 8KlwQuSGHunMeePGhaZfKUFnWv4bvHmod2NlP7nxQ9eKn+zTC2/d9V0y+LAhh0f1QHZ1 6Js1DSLhfM4LRVyrdiEocPlFZbioggMqsCfzajAChbu+5GGcPKO3rDQYOaNpuJKxiuIv oUwDnlnOjNz56pxCEPL8T6IluM/0FqkE5FoZtfgrFIv30qPeCbSTBqEA3ef3XkuWGOtc woBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767149733; x=1767754533; 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=mHQgO64N0mSOshA8/jcIaTzSFR+k9jE4B9vdvYmYNSA=; b=LQPW4A1D+IYAbmGSpiC+2VnxBRX4c2qPh5sHxsxx2zp3BbOYFESq4vS12P8bEYWMXF z3UOGS7Gcs7RC/BuFHflAxVIvuG47S0dEiEnkcBuQ+LnOKl9LE4ufINgVJXzS4e57Tyi gI4Ua/qbMlYUKth5Emfk6Fd9N7+KQy6DZ1dtZxhrxlN9tUMHeNwI+nu34GaZyeXfju2+ aWlKXfeKnN6OY7A50Fc3llaSDpCi3LtNZxhYPBp5rB6shyIG+I6lmP401BH72ApnXtKr 5iwH0LqVoeBzkyMrLirijUFuVhoZopwo0Gn++wMv0K9og6HzzDYNzAb+dMU91nKsyuvF PGZA== X-Forwarded-Encrypted: i=1; AJvYcCXLfolrHdEUqhheBv5w3iN4NwlDwai0JNE9N2L3rA8Z5H0OELrjF7Y+0kIfCDd7LCBsRFC/1MErlamdyTY=@vger.kernel.org X-Gm-Message-State: AOJu0Yyu3UnaRoZWq4b9N/IwnIltmQByiGXCRWHP3cak9APnrsUvAoDB WxBQ+/d4CPXMvewl4Hk9K+ass3thdNum67/GZKTlFX2uGKhso5Jui0ft X-Gm-Gg: AY/fxX4iQrm4pmHrk2au/tXk4D/8YyspL5W8KUId27vJmrezXHH1S8KMD8qSkFbBkmb VvLIQtvWWa+8cex3Fe2hLsc1byY6ATjf03fQcw+iyNlPQJeeE3XBQ2M/t2z/nSNUXyEtMbooJxr jIzlWyhaMZdiK1v6ahNnjNO0NJ61DYceSEKXzWJBmp+v3hcpgA3frPcVonL77GYYCFJ+wBtoFt4 HnbVK0sAusgIjCK0ux+ZwBsHMUKc+ezIqiJpAzohtSPyy4Sq1/IGH+99p2j6tXbs8YnVQRQzuYK J78obOgZg2IKLtgk8WPofvREf85CLBmCKd96ZcrRqRmST7/emm4VuK7vWON+OWGfywL5PA7Qnju hZ/9o218eVARehlUJva327R7z4id5axcK83HARCOIb6BcV6LuP2ub5qNKE0NTKwpIV8gzcGeRw0 uozUlG5lG8Mgvw X-Google-Smtp-Source: AGHT+IE/6+hfXayWM1JdWA9o6vJZIBu0G6SoALMz31yXzlT5yBq/IAL6FIfaJeCzxB1pm8U2r9/1vQ== X-Received: by 2002:a05:6a00:8e02:b0:7b8:8d43:fcde with SMTP id d2e1a72fcca58-7ff52d3852cmr33628015b3a.8.1767149732685; Tue, 30 Dec 2025 18:55:32 -0800 (PST) Received: from celestia ([69.9.135.12]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7e892926sm33623646b3a.66.2025.12.30.18.55.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 18:55:32 -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 5/5] ceph: Fix write storm on fscrypted files Date: Tue, 30 Dec 2025 18:43:16 -0800 Message-ID: <20251231024316.4643-6-CFSworks@gmail.com> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20251231024316.4643-1-CFSworks@gmail.com> References: <20251231024316.4643-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 grossly 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. 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 b3569d44d510..cb1da8e27c2b 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.51.2