Comment 1 for bug 1900993

So the ...#1.data files are non-durable fragments -- which is to say, during the PUT,

 * the proxy received 100 Continue responses from at least ndata object servers,
 * it sent the data and footers out, but then
 * it didn't receive enough acks to tell the object servers to mark the fragments durable.

(Alternatively, the proxy *did* attempt to send it, but the message was lost so the object-server never acted on it. In that case, hopefully some of the other object-servers did receive the message and the reconstructor will eventually make the other fragments for that timestamp durable as well.)

At the moment, only the ...#1#d.data file is durable, so only fragments with a timestamp before 1602271734.07438 can be cleaned up. The object-server keeps the non-durable fragments around for a time (see reclaim_age in object-server.conf-sample) in case some other server has a durable copy.

To resolve it, just wait -- eventually the non-durable frags should either be deleted or marked durable.