Re: efficient removal of old objects

[Sage Weil <sage@xxxxxxxxxxxx>]

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