public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Kefu Chai <k.chai@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH ceph tentacle-stable-9] backport fix for scrub errors on EC pools with optimizations enabled
Date: Tue, 20 Oct 2026 17:09:24 +0800	[thread overview]
Message-ID: <20261020090924.2590476-1-k.chai@proxmox.com> (raw)

Without EC optimizations, every shard of an EC object is padded to the
stripe boundary. Once allow_ec_optimizations is set on the pool, a
truncate shrinks only some of the shards. The rest keep their padding.

For the user this means deep scrub reports the object inconsistent,
and "ceph pg repair" makes it worse. If more than m shards are too
long, repair marks them all missing and the object ends up unfound,
even though its data is intact. To get the PG clean again, the
operator is likely to run "ceph pg mark_unfound_lost delete", and that
does lose the object. RBD hits this most often, as librbd sends a
discard or write-zeroes at the end of an object as a truncate
(https://tracker.ceph.com/issues/81915).

The fix is under review for main
(https://github.com/ceph/ceph/pull/72853) and has no tentacle backport
yet, so no point release carries it. Carry my cherry-pick until then.
It leaves out the new unit tests, which tentacle cannot build, and
drops out on the next rebase.

Signed-off-by: Kefu Chai <k.chai@proxmox.com>
---
 ...n-truncate-padded-shards-of-legacy-E.patch | 62 +++++++++++++++++++
 patches/series                                |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 patches/0019-osd-ECTransaction-truncate-padded-shards-of-legacy-E.patch

diff --git a/patches/0019-osd-ECTransaction-truncate-padded-shards-of-legacy-E.patch b/patches/0019-osd-ECTransaction-truncate-padded-shards-of-legacy-E.patch
new file mode 100644
index 0000000000..079103dee0
--- /dev/null
+++ b/patches/0019-osd-ECTransaction-truncate-padded-shards-of-legacy-E.patch
@@ -0,0 +1,62 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Kefu Chai <k.chai@proxmox.com>
+Date: Tue, 20 Oct 2026 09:31:50 +0800
+Subject: [PATCH] osd/ECTransaction: truncate padded shards of legacy EC
+ objects
+
+Without EC optimizations, every shard of an EC object is padded to the
+stripe boundary. After allow_ec_optimizations is set on the pool,
+truncate() only shrinks the shards whose optimized size, computed from
+the old object size, is larger than the new one. The other shards keep
+the legacy padding, so scrub finds them too long and flags the object
+inconsistent.
+
+With 4+2 and 4K chunks, all six shards of a 20K object are 8K.
+Truncate it to 16K, and shards 1-3 stay at 8K instead of 4K. RBD hits
+this when a discard or write-zeroes reaches the end of an object,
+since librbd sends that as a truncate. With more than m shards
+flagged, "ceph pg repair" marks them all missing and the object ends
+up unfound, while its data was fine.
+
+So truncate the remaining shards to their new size as well. Objects
+written with EC optimizations already have that size. Extending the
+rollback clone to cover the padding instead doesn't work: the primary
+doesn't know how long it is, and BlueStore rejects a clone_range past
+the end of an object.
+
+Fixes: https://tracker.ceph.com/issues/81915
+Signed-off-by: Kefu Chai <k.chai@proxmox.com>
+
+(cherry picked from commit 344c82f845f76017a0854cf3b6f9d3609b561131)
+
+Conflicts:
+	src/test/osd/TestBackendBasics.cc: dropped, tentacle does not have
+	PGBackendTestFixture which the new tests are built on.
+---
+ src/osd/ECTransaction.cc | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/src/osd/ECTransaction.cc b/src/osd/ECTransaction.cc
+index cd03849ed4d4..41bad83bf334 100644
+--- a/src/osd/ECTransaction.cc
++++ b/src/osd/ECTransaction.cc
+@@ -714,6 +714,19 @@ void ECTransaction::Generate::truncate() {
+           start_align_next);
+       }
+     }
++
++    // Shards of objects written before EC optimizations are padded to the
++    // stripe. Trim that padding too. It is zeros past the end, so it needs no
++    // rollback.
++    for (auto &&[shard, t] : transactions) {
++      if (truncate_eset.contains(shard)) {
++        continue;
++      }
++      t.truncate(
++        coll_t(spg_t(pgid, shard)),
++        ghobject_t(oid, ghobject_t::NO_GEN, shard),
++        sinfo.object_size_to_shard_size(op.truncate->first, shard));
++    }
+     rollback_extents.emplace_back(make_pair(clone_start, clone_end - clone_start));
+     rollback_shards.emplace_back(clone_shards);
+   }
diff --git a/patches/series b/patches/series
index f6b8fda5f7..597d782c0b 100644
--- a/patches/series
+++ b/patches/series
@@ -19,3 +19,4 @@
 0015-bluefs-truncate-unused-allocation-on-close.patch
 0016-bluefs-fix-use_direct_io-override.patch
 0017-bluefs-acquire-file-lock-in-truncate.patch
+0019-osd-ECTransaction-truncate-padded-shards-of-legacy-E.patch
-- 
2.47.3





                 reply	other threads:[~2026-10-20  9:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261020090924.2590476-1-k.chai@proxmox.com \
    --to=k.chai@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal