Hi Sam, * snapshots/clones:
I assume we don't want to support snapshots/clones for erasure coded PG. If automatic tiering is implemented, snaphoting an object would be possible when a replicated PG is tiered with an erasure coded PG. The erasure coded PG would be used only for demoted objects coming from the replicated PG (if they are not read for given period of time, for instance). But what happens with objects that have snapshots ? The tiering policy could be to never demote an object with snapshots/clones. And to automatically promote an object when a snapshot/clone is created. * watchers The on disk info about watchers is included in object_info_t and will be persisted on each chunk in the OI_ATTR. Since there will be more chunks ( typically from 5 to 15 ) than replicas ( typically from 2 to 3 ) it means it will use more disk space but I'm under the impression that the average number of watchers per object is big enough for this to be a concern. The in core structure and the associated logic does seem dependent on the resilience policy. It could be moved entirely to the PGBackend implementation if it's common to both. * PGBackend + PGBackendInterface It would probably help testing if the proposed PGBackend interface https://github.com/ceph/ceph/blob/wip-erasure-coding-doc/src/osd/PGBackend.h was isolated in an abstract PGBackendInterface. ReplicatedPGBackend could inherit from PGBackendInterface and PGBackend ( which would contain the common watcher related code, PGRegistry etc. ). That would allow unit test code to synthetize behavior by provding PGBackendInterface to PG. https://github.com/ceph/ceph/blob/wip-erasure-coding-doc/doc/dev/osd_internals/erasure_coding.rst Cheers -- Loïc Dachary, Artisan Logiciel Libre All that is necessary for the triumph of evil is that good people do nothing.
signature.asc
Description: OpenPGP digital signature
