Same as FilOzone/filecoin-services#451; we overestimate the actual size of the data by nearly 0.8% by taking leaf count as it is. Leaf count operates over the virtual fr32 expanded data which is not stored on disk and not charged. We just need to do leafCountToRawSize as per FilOzone/pdp#266 in here. But we also should document in the API that we're overestimating by up to 32 bytes. This is the value we use to charge for the data set, it's just not the precise value of how much the client is storing. An accurate amount would be obtained by iterating over piece CIDs and decoding raw size from the CID but that's costly. It could be documented at least as an accurate alternative for those that want it.
Same as FilOzone/filecoin-services#451; we overestimate the actual size of the data by nearly 0.8% by taking leaf count as it is. Leaf count operates over the virtual fr32 expanded data which is not stored on disk and not charged. We just need to do
leafCountToRawSizeas per FilOzone/pdp#266 in here. But we also should document in the API that we're overestimating by up to 32 bytes. This is the value we use to charge for the data set, it's just not the precise value of how much the client is storing. An accurate amount would be obtained by iterating over piece CIDs and decoding raw size from the CID but that's costly. It could be documented at least as an accurate alternative for those that want it.