On Tue, 5 Dec 2017, Sage Weil wrote: > Can we figure out what problem the complex approach solves that the simple > approach doesn't? I think the values are something like: > > master pool-proposal 2pc-pg-update > per-object sparseness x ? ? > per-pg sparseness x > per-pool sparseness x x > > I put ? because for a single object we can just query the backend with > a stat equivalent (like the fiemap ObjectStore method). This is what, > say, rbd or cephfs would need to get a st_blocks value. > > For a 'ceph df' column, the pool summation is what you need--not a pg > value. > > Is there another user of this information I'm missing? > > AFAICS the only real benefit to the 2pc complexity is a value that remains > perfectly accurate during backfill etc, whereas the pool-level summation > will drift slightly in that case. Doesn't seem worth it to me? I should add though that I'm not sure how well the pool-level stats will work out. I think for BlueStore it means a new key, one per pool, with a summing merge operator. We already do this for the overall store stats; this will either supplement that (2 small keys) or replace it (we can add the pool values up to get the overall value) so that there ar ethe same number of updates but they're spread over per-pool keys? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
