Handling Out Of Storage Errors From the Host
Sometimes when we upload to a host, it returns an out of storage error. We need to mark this host as !GoodForUpload but the host can stay GoodForRenew if the score is high enough.
This means that we need to track somewhere in the contractor when a contract has started returning the out of storage errors. And in threadedMaintenance
, if we see that the contract has recently been returning out of storage errors, we mark it as !GFU
I think the best way to do this would be to add a timestamp for RecentOOSError
, and if that error has been returned within the past 7 days we keep it as !GFU. If the error is more than 7 days old, we assume that the host may have had time to add more storage or clear some things out so we're willing to try again.
This is out of scope for this issue but I wanted to add some context so that we address this issue in a way that makes it easier to solve the following related problems:
- I don't think the contractor currently handles other errors from the hosts well either. There's this 'interaction score' that the contractor feeds to the hostdb, but I don't think it's enough. Because of the cooldowns, if a host is consistently problematic for the host it may actually take a substantial amount of time for the interaction score to get the host marked down and disabled.
We really want to be as on top of the capabilities of our hosts as possible. If we can see that a host is struggling to give us downloads, we want to recognize that. Or if the host just has general connectivity issues, or if the host for some reason has errors for certain types of RPCs but not others. We should be marking a host !GFU and !GFR accordingly as it's unable to perform certain actions, but defining all of those actions may be a challenge.
- The hostdb itself currently penalizes hosts heavily for not having enough storage. And actually, I'd like to update the hostdb to zero out the score of any host that has less than 200 GB of free space. The challenge with this is that if we already have a contract with the host with a ton of storage on it and we like that host and want to keep that storage, the hostdb needs to be aware of that.
So we should probably be passing a list of active and passive contracts to the hostdb that show which hosts we are connected to and how much storage we have with each host, so that the host can take that into account when scoring the host. If we already have a large contract with a host, that host should be completely immune to all low storage penalties as the low storage penalty only exists to keep the renter away from hosts that may not have enough space to be interesting.