Piece_expiration.db and collector service increased use of self expiring pieces?

[Toyoo]

@thepaul

@CutieePie

Why isn’t the who collector expired pieces code deleted, and left to the GC to handle removing the expired pieces - I understand there’s allot of rework there currently but it seems logical to bundle the expired deletes into this process.

I think that’s entirely reasonable. For my own part, I wasn’t aware that the expired pieces collector was causing any issues for anyone. (Maybe some of us were aware; I’m just saying I wasn’t.) The collector only exists so that nodes can opportunistically remove pieces that it knows it doesn’t need to store anymore, without waiting for the next GC bloom filter. If that isn’t helping, let’s get rid of it.

I don’t see any problems either on my nodes. If anything, piece expiration is a more efficient mechanism. GC would need to first move pieces to trash, only then remove them. Piece expiration saves I/O time.

And so, well, if a node gets a lot of pieces with expiration date set and complains about I/O, using GC to clean them up will make the I/O worse.

If there is an I/O problem with piece expiration, I would seek to solve it, not remove the mechanism altogether. Quickly looking at the code, there’s one potential improvement to be tried: running a single DELETE statement to remove entries of multiple pieces in a single transaction, as opposed to removing them one by one.