Oh, thanks. I checked it like you suggest before, but results are somewthat strange.
Most pieces uploaded have size like few kB.
But it solves my other question - how my node can get 100k+ uploads in half a day, but ingress bandwidth is only like 20GB
Why assume when you can verify ? You do know @BrightSilence has posted earnings script which uses databases so when he says its there, it should be there. He never posts without valid claim.
The title is stating Question about upload data size, not deleted
However, it has this data too, include pieces in trash. You can use the join with table piece_expiration.db to figure out, which pieces are currently in trash.
Also, why do not use your filesystem to check that out?
find /mnt/storj/storagenode/storage/trash/ -type f -printf "%s %f\n"
Every deleted piece has been uploaded at some point. Its size is then lost if the piece if deleted and garbage-collected. This is the information I wish I had in the logs.
For post analysis it’s highly recommended to use some kind of log collection service and monitoring system in place.
The storagenode will remove the information regarding deleted pieces when they will be deleted from the disk, you can collect this information only while it is in the trash. You have only 7 days for that.
For that to be implemented the node would have to keep more information on deletes in its db’s. I’m guessing this will be a new action in the existing tables in bandwidth.db. however, that data gets aggregated (rolled up) quickly to prevent the db from getting very large and slow. So you won’t have per piece information. But totals would be there. This is however still speculation on how that may be implemented.