An expiration API seems sufficiently general and useful to ignore the other bike shed options. I don't buy the readonly vs readwrite issue with scrub triggering deletions. On the other hand, having scrub trigger it is a problem in general because the time periods may not align. It would make garbage collection only useful when it is on the same order of magnitude as scrub. Viewing the deletion workload in isolation, doing it from scrub is significantly more efficient. (Assuming it is implemented well. I think the current scrub needs to be reworked before that could happen.) However, in general, deletion is only a fraction of the overall system load. In fact, we'd have one deletion to follow up every overwrite PUT, so we effectively double the number of write ops if the client does it for that case. I don't think that will be a large part of the workload. Doing it from the client also means we can control the period independent of scrub... e.g. 1 hour instead of a day or days. In any case, I think we should leave it on the client, at least for this sprint. We need to make the scrubbing incremental first. 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
