Feature #14041
closedFeature #14031: EC overwrites
EC overwrites: deep scrub and checksumming
0%
Description
EC overwrites preclude our current checksumming strategy. Instead, on each shard, we'll maintain a set of omap entries (prefixed so that we can use the omap space on the object for other things later) where each entry contains N per-stripe checksums. N should be configurable at pool creation time or when the pool is switched to allow overwrites (and is fixed forever after). Notably, we need to be able to switch an append-only ec pool to allow overwrites.
When an object which was written in append-only mode is overwritten, the OSD should clear the append-only checksum attr, set the checksum for the modified extents, and initialize all of the other block checksums to a value which indicates that it is non-determinant. When an append-only object is deep-scrubbed after the mode is switched, the correct checksums should be immediately written out.
We also need a cache for unstable checksums.
As with several of the other features, this feature is complete once when the ec overwrites testing flag is enabled, current ec pools use the new checksumming scheme.
Updated by Samuel Just about 8 years ago
- Subject changed from EC overwrites vs deep scrub to EC overwrites: deep scrub and checksumming
- Description updated (diff)
Updated by Samuel Just over 7 years ago
- Assignee set to Tomy Cheru
Aravind doesn't appear to have an account.
Updated by Samuel Just over 7 years ago
Some thoughts.
We can actually store all checksums for all shards if we mediate them through the write-ahead log entry (we have to do this anyway, actually) and give up on the "no writes, even little-bitty ones, on non-participating shards" thing. Once we've gone that far, we could just throw caution to the wind and update the stupid object_info.
Updated by Josh Durgin almost 7 years ago
- Status changed from In Progress to Closed
We ended up relying on bluestore's checksums for this.