Bug #11455
Updated by Loïc Dachary over 8 years ago
On at least Giant and Hammer, COPYing an object onto itself (e.g., to change its metadata) reliably produces a truncated object, *if* the source object was originally created with an older rgw (tested with Emperor) using a non-multi-part upload. If the object was originally created via a multi-part upload, or was created with a newer rgw (tested with Giant and Hammer), the problem does not occur.
The truncated object has correct metadata, including the original size, but the underlying RADOS object is smaller. When a client attempts to fetch the object, it receives less data than indicated by the Content-Length, blocks for more, and eventually times out.
How reproducible:
always
Steps to Reproduce:
1. Install dumpling
2. Create object > 512k
3. Upgrade
4. Copy object into itself (modify attributes)
Actual results:
Object cannot be read successfully
Expected results:
Object should be read successfully