From nobody Sat Feb 7 21:05:37 2026 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 8B0A92C326F for ; Wed, 7 Jan 2026 21:02:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767819742; cv=none; b=XkQWuxNQa6XETs2RcBxKfXkAecgIS1r0Xr5E68rFEbCFr/y4UqCKT+B7ittqlHMSQH+cax5LaXEs7MKVGsPuReJawuNYuZPveHA6/biwulomEyR8BdDUKfOqeEai1x0SxS5+++SoU0ZNW4F/OnyscDF+6vHJi9KFhpar++tA8jQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767819742; c=relaxed/simple; bh=O4kJF9S8XzpGPOZTeoLxtkvaxDvktVpfrz2nWxquEuA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PWAZrJUluuH/ipBHWgZIPRPJP+LF/fO6TBlYlw3FjG+3RlNlL6Ll81BvRK6/ngXkz3+oCKLpxUnqRvdunTwxIRHR3vXB1YJJw+3yN65c5BzIt+HUEDQDvpFzkzs7TjiZsgEKSGlNG5MJrHNXUShB4MuS8gMa2x1w52VUlTjycRg= 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=YZ228q7n; arc=none smtp.client-ip=74.125.82.177 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="YZ228q7n" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-2ae38f81be1so2145892eec.0 for ; Wed, 07 Jan 2026 13:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767819738; x=1768424538; 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=MJJ0g2KBjvWnpkx/2r0sdFCRqcFFwKJ2lW+TX7dGrPo=; b=YZ228q7nU+FpFr8bxyTL76iqoG32WY9xJ+K9pzlxW8VuxBZabMuBFAgj3LkdxQmyfP ocmwlOXATpEs9sGfgR2Bmi0OGNGLyuS7Vt88FWTvUe7/FdFqQktOuMLEtTGRCowjIc6F 7MV27qtOpokvJ51mWpaexNliACUHhjd5wcHOFmjh4M8SsqrjWkZagWMzm1qtbmkNYkX7 8xwn7Fy/eLxm/bz3DXeiOneMOU2mufMHPrctG+2f8KpPlkBN670L1bvMmnpiKy9amdxc +BEoKFMLIEcVVEUejpGE+pO24FNgEE1ceTuiEjrItp1l/6DPxq+FpDftivcr+U7aFn6a VivA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767819738; x=1768424538; 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=MJJ0g2KBjvWnpkx/2r0sdFCRqcFFwKJ2lW+TX7dGrPo=; b=qkow9c8BD9ShHGlVCv4SeJuaTkiEQxbISNVlQzE8bMCIxz6bberfvcwV5Ej99hU3tz VE8k1v+YycIZ43+WYLhnU2+LVD8l9Ep8TSCpRrmiD7PFuD3i80eCI9En8xRv4PltgA8d xe+VCWjYO0pa2vZx3hSFbyegH+xGMwIj1nHFMrE/j/mMKKJs2sCQ6n+z/imuqgs9AgPa 7Y09VAAN3KUbLE1SFNVXJlBxjGmS7epWlw6yOwiP7qWBkuUQnPv/xLV4vWr2xnNgwKfl f78c0hvB1QJ/LzUN8A5Iik/czVkthfYDneI727y9tU9XokTFwntDeSI6ax/r+ao1RwzB Aq/A== X-Forwarded-Encrypted: i=1; AJvYcCV9o+s1d7J5RNnO6mRVTxHPNfAQRRJF/BKaBFn88NP1EEg8CLZ4OSGS9rK+iuEy1r/lXMGn8FtjgA/n8vY=@vger.kernel.org X-Gm-Message-State: AOJu0YxyW3KIdAlj0/Df9gjP1uA+UFeY6bq8sdPk6w/NNpK10hT+uZdn oCeYpSyE8mHnjVv7/wAwQhBvQx6hzZ5ib056b5RbPTSjL6T3eUNTRmB5 X-Gm-Gg: AY/fxX4whDtT+IuSvbfQel5+jt6s0xt+bb5tUQseI0aQUsdDr/GR2Om12j7BbVLDisW 3oqJUDoy0i7zL1yA6Mk8/mmQaJHPubwmabnpfqKdYEtTr+5kWyis9SqJbdaoK56vQ+yzz0F71Rl M38zsbxSV0QOK79vOvwxZjf0RPiHTAx8GoaCQ7iLl26Mv/NpJxw4nifKge5jY/njfaRcvU/5Zu8 NeFg/CiSuafIbtJ5Hb0fZtzmvsHRnXDuXjnbY9DWlQOaDC7AcQRidvYjDd0Vr/a3iIl6YMJzJad X+6r7/jwvkxWdaxkTyir5OVEN18rBbTo3Oj+w6DBn6S23evCazB1/+nGK/d315NNWBqAJQWm+YR hcRZrZ1vY8jkqL1ixh9QD2z23Mc0D1BdaV1sCKE23JLzACXZ0ut1os78dFWAgFvgPCF11g2MFxH uQAWWx2ib3u2fcSMHRGeRR6KOH1fiZv9yKpwqhJDZi2gfqIHyqy3FEULjU4OGm X-Google-Smtp-Source: AGHT+IFiXkVljkFfXOH3V04S1IN5M4BxUMOD54SyXL1mMom6Qzw8P2Jruw0xmxP9w0kMsCs2QmlqOA== X-Received: by 2002:a05:7300:4347:b0:2ae:582b:db80 with SMTP id 5a478bee46e88-2b17d1f023emr3128728eec.9.1767819737617; Wed, 07 Jan 2026 13:02:17 -0800 (PST) Received: from celestia.turtle.lan (static-23-234-115-121.cust.tzulo.com. [23.234.115.121]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b170673b2esm7730320eec.6.2026.01.07.13.02.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 13:02:17 -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 v2 6/6] ceph: Fix write storm on fscrypted files Date: Wed, 7 Jan 2026 13:01:39 -0800 Message-ID: <20260107210139.40554-7-CFSworks@gmail.com> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260107210139.40554-1-CFSworks@gmail.com> References: <20260107210139.40554-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. 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 f2db05b51a3b..b97a6120d4b9 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