Hi Myoungwon, I was thinking about how a refcounted cas pool would interact with snapshots and it occurred to me that dropping refs when an object is deleted may break snapshotted versions of that object. If object A has a ref to chunk X, is snapshotted, then A is deleted, we'll (currently) drop the ref to X and remove it. That means that A can't be read. One way to get around that would be to mirror snaps from the source pool to the chunk pool--this is how cache tiering works. The problem I see there is that I'd hoped to allow multiple pools to share/consume the same chunk pool, but each pool has its own snapid namespace. Another would be to bake the refs more deepling into the source rados pool so that the refs are only dropped after all clones also drop the ref. That is harder to track, though, since I think you'd need to examine all of the clones to know whether the ref is truly gone. Unless we embed even more metadata in the SnapSet--something analogous to clone_overlap to identifying the chunks. That seems like it will bloat that structure, though. Other ideas? sage _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
