]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
rgw: copy_obj_data() record uncompressed size for a compressed source 70006/head
authorOguzhan Ozmen <oozmen@bloomberg.net>
Tue, 7 Jul 2026 12:27:14 +0000 (12:27 +0000)
committerOguzhan Ozmen <oozmen@bloomberg.net>
Tue, 7 Jul 2026 13:00:17 +0000 (13:00 +0000)
commit5addb80abac1f19cc779744150b8d9b8aebb8f93
treebea4d335ea110ae184c705d28577ce9678613a76
parentc11c7144fc77e331fa0b23a5298742bfe68afdd8
rgw: copy_obj_data() record uncompressed size for a compressed source

When copying an object and a compressor/encryption processor is configured
for the destination, the bucket-index accounted_size was set from `ofs`. If
the source is compressed but the destination is not (re-)compressed (e.g.
compression is off, or rgw_compression_type=random rolled no-compression),
then `ofs` is the compressed size, not the logical size.

In multisite this diverges from the peer zone, which recomputes its own
accounted_size via fetch_remote_obj() (already corrected in #63306).
ListObjectVersions then reports different sizes per zone.

Pass along the source's logical size (astate->accounted_size, derived from the
object's own attrs and correct for plain/compressed/encrypted) into
copy_obj_data() and use it when the destination is not compressed. The
rewrite_obj() and transition_obj() callers pass 0 and keep the prior
ofs-based behaviour. This is the copy_obj analog of the fetch_remote_obj
fix in #63306.

No on-disk/encoding change; corrects newly copied objects only (existing
index entries are unaffected) and is safe across a mixed-version upgrade.

Fixes: https://tracker.ceph.com/issues/75716
Fixes: https://tracker.ceph.com/issues/75715
Signed-off-by: Oguzhan Ozmen <oozmen@bloomberg.net>
src/rgw/driver/rados/rgw_rados.cc
src/rgw/driver/rados/rgw_rados.h