Hi everyone, first of all, please tell me if this is the wrong place to ask question like the following one. I recently had a closer look at erasure coding performance with bluestore osds (I'm a ceph admin and currently looking into ceph's internals). Therefore I added a couple of printf-statements to trace the operations through multiple osds, specifically the ones in this commit: https://github.com/erbth/ceph/commit/116a44c35223830912056874019adfe5cf3c7ee... . I used 4k random writes to trigger ec overwrites, because I wanted to observe the latency implications more closely, and would have expected to see read ops on all osds with a data shard, followed by write ops on all osds of a pg for each client operation. However I found two phases of writes after the read-phase, which means that every shard is written twice - hence increasing the write amplification, which is intrinsic to erasure coding, even further (e.g. for 4+3 ec it would be x18 instead of x11). I believe that this is caused by the dummy-operation started here: https://github.com/ceph/ceph/blob/v19.2.3/src/osd/ECCommon.cc#L902 at the end of every ec transaction. I don't completely understand how this code works, but I would assume it should not cause a second write-phase but just update/sync metadata? - Anyway, as far as I understand it will trigger another write roughly at this point: https://github.com/ceph/ceph/blob/v19.2.3/src/osd/ECCommon.cc#L745 , because the read-modify-write pipeline treats it like a 'normal' all-reads-finished condition. (I've tried to skip the write phase using this patch: https://github.com/erbth/ceph/commit/2c1bb045f272769f714a8f06c4153b25cceaf1d... .) Is this really a bug, or required for some reason? If it is required, could you briefly explain why (I'm just curious)? I based all my experiments on ceph 19.2.2 and 19.2.3, which means that this behavior might have already changed in the current main branch. Regards, Thomas