From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f49.google.com (mail-dl1-f49.google.com [74.125.82.49]) (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 EB03D1B87C9 for ; Mon, 26 Jan 2026 02:31:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394667; cv=none; b=ldYYkQ0dVy41ErDvTIN1qirs98tSEmjclxkxOTcatdH+P0mtp6JeM3xGLEl/MFe3iN9Ad6Eem44CuwTNvTaYyjx5segGia1upzvLskBRPo4IVOV9QyBtBeUn5PNsz8RlWiH+E0EHcOiX89RY6UWd4Stvq8WmCcp/7Jnmtv+AyYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769394667; c=relaxed/simple; bh=mrQWcprsJ7tXA+6MiR721zXu/D/Xf6tHUu5xYUHWluk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=rvpZXQLA84YChjufo14tC8xPdtYpB91Ql1Y0D6HYVXc51/4RVrYrY6ahbwFE+Q88kS9XExIOMJeH3ecSAV/b5ZSxVcXvJXP7vajlZ9m44bNvAfiam4NlADl88g/z5T067kn0A3p1Yn4f6DqWfxkC59mgtrtQAkQe7HYFgLozhWY= 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=iNWNF8pE; arc=none smtp.client-ip=74.125.82.49 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="iNWNF8pE" Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-12331482b8fso1216217c88.1 for ; Sun, 25 Jan 2026 18:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769394665; x=1769999465; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=o53HDt0q1CVwbi/zSNV9kLXIizI6aM8edUoYkNZlqJg=; b=iNWNF8pE41M8u7KIRcWyesy0I8iG3c/hIJG/xzyDxxrXPnCBn2n7W7+ZxRi8v7uO31 5eTKGQSlcINetcczxbKIFJm7TZGxl2OlKaApR7e0YTenpuVuGUb5CEnf7Nme8+Gt+3eD qFNj2/IQaKfbXgzqpX97ePGLSVLsfQu/Tp80CcJBfRHsgthVyJuyvc/GMwi9d503lsaT zKl/rW5AHceFyv6rmQRioCvH9T7HssbfEJWOHebv5+Cv7fazSqAYIUkA6RwsBdPeAEv4 NnQ3rlgzpMg8kY/9PPug7kcRyCGgE2wvdj/tUxiMzprnVnNihsCLyzxjPmGI/DpxoJlJ yGFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769394665; x=1769999465; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o53HDt0q1CVwbi/zSNV9kLXIizI6aM8edUoYkNZlqJg=; b=q2v+hK1EMnWbe9/uILoKT6P2kEVFkmMSXQvVox96FbAJCvYIRr+mjHP0gxay8rri22 7Qpwx3IWOQSsNFVYIe3sx3Zbdd0HgMI0P8XhTbHTVXZ2uW4m6eO3CZqQA7hCrriCBup+ 7AjK90fbuPgmNxDXhY2ZWFQe6837jfzAyK6eDQEfk20E0DSFbvOU2xB0b8gPwp/82esd 5R4zAZG4+E8aNiab8rSI8kaqW3Rbc4AoaX1LAwYRy1CqJfJTBF8tOkrLORA1k5UaVKHF Nc/1meiAEs6c951PlPv2XoforSNJZTRdQz1m8NYjbEz6fdhHPyiGNR3KlFnuy0wbUdr2 vRmA== X-Forwarded-Encrypted: i=1; AJvYcCWe1xNZKmxQ9lF/nf+DEgQyorA9rS1sYOI/C62Hht90Z8mP9RqA7f8aMZMf6PXWVxECqUiUOks3CwxMEVo=@vger.kernel.org X-Gm-Message-State: AOJu0YwvWMV12ou86Sp96TdADrWE8zOMVU7erA7DZy4Ag+QZ38ALz28Y WJVSbcPYXfqjLz4TjMokiA4y+OVHKz2OnW+m6x9qKH4Iee2ekCIXqwtE X-Gm-Gg: AZuq6aINfAhjUttTD2KctRntw5Rjy8PQ1ysU6Hu/IMcF0vRV2fNXw2YFnGs1LECI0xn Kq2uji2nfl/TykvEh0gvNvN0OQ5Qw5y7mBJjz5kYmcBB3dkCcwrnW1mO2uS+ToRzo3OepFeBUZu GHDA4rtel6B89AEAqUEm9WqlcKSBC9ErxecPmfCbTioRaRiNRC1nzIojJrZbnr8JCigQz6SHTx9 Vib3gxeLy9icwXo50JTMZszp6Sf0aO0gnAsAzv9UkoeqfGUiH/yZ80eNP++3hvDVU6AQfrBbxi6 5+URH56MpWPyq5jz8Di4q+oKRatqa9BVIoEqHEelHh9l/AYykvK8RVUjjTNiXAvEK15FmiaPahT ZwTWYcqPNcwFDoWh8N3G4hJ/kExu/YbxEpBpNpilGq8Ad22RKc0B+/cb1bMS+2Bx3JxCm1R85cN fEL9PW+rVmu1vM/vhUMR241w+5hIbGSd32y9DvJikefOC1/zb4DoZe X-Received: by 2002:a05:7022:914:b0:11e:3e9:3e99 with SMTP id a92af1059eb24-1248ec877bdmr1892191c88.49.1769394664769; Sun, 25 Jan 2026 18:31:04 -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.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 18:31:04 -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 Subject: [PATCH v3 0/4] ceph: CephFS writeback correctness and performance fixes Date: Sun, 25 Jan 2026 18:30:51 -0800 Message-ID: <20260126023055.405401-1-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello list, This is v2 of my series that addresses interrelated issues in CephFS writeback, fixing crashes, improving robustness, and correcting performance behavior, particularly for fscrypted files. [1] Changes v2->v3: - Split out two patches ("ceph: free page array when ceph_submit_write() fails" and "ceph: split out page-array discarding to a function") to a new series [2] since they are independent and had no outstanding review comments. - Lowercase the subject lines of commit messages, per subsystem-local style. - Update the commit message of ("ceph: fix write storm on fscrypted files") to mention the explicit dependency on ("ceph: do not propagate page array emplacement errors as batch errors") for correctness, to prevent the former from being accidentally backported without the latter. - Reorder the series to make the aforementioned patches consecutive. The series cadence is now: bugfix, bugfix, cleanup, cleanup - Add a clarification to ("ceph: remove error return from ceph_process_folio_batch()") that "abort" logic is still possible, just that it is responsible for cleaning up after itself. Changes v1->v2: - Clarify patch #1's commit message to establish that failures on the first folio are not possible. - Add another patch to move the "clean up page array on abort" logic to a new ceph_discard_page_array() function. (Thanks Slava!) - Change the wording "grossly degraded performance" to instead read "correspondingly degraded performance." This makes the causal relationship clearer (that write throughput is limited much more significantly by write op/s due to the bug) without making any claims (qualitative or otherwise) about significance. (Thanks Slava!) - Reset locked_pages = 0 immediately when the page array is discarded, simplifying patch #5 ("ceph: Assert writeback loop invariants") - Reword "as evidenced by the previous two patches which fix oopses" to "as evidenced by two recent patches which fix oopses" and refer to the patches by subject (being in the same series, I cannot refer to them by hash) Warm regards, Sam [1] https://lore.kernel.org/all/20260107210139.40554-1-CFSworks@gmail.com/ [2] https://lore.kernel.org/all/20260126022715.404984-1-CFSworks@gmail.com/ Sam Edwards (4): ceph: do not propagate page array emplacement errors as batch errors ceph: fix write storm on fscrypted files ceph: remove error return from ceph_process_folio_batch() ceph: assert writeback loop invariants fs/ceph/addr.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) -- 2.52.0