Replying to zooko:
I'm pretty interested in taking this design to the extreme to get the best efficiency. In that extreme, we never go to persistent storage for either read or write (or existence check) — which requires at least a disk seek for a direct-attached-storage backend or at least a cloud service API request for a cloud backend — unless the leasedb told us to go to persistent storage. (Except, in the case that we're currently building or rebuilding leasedb by crawling persistent storage.)
I agree with returning a positive response to an existence check (DYHB) when the leasedb says we have a share. The case where we turn out not to actually have the share is an error that the downloader, uploader, or repairer should tolerate anyway.
I think that returning a negative response to an existence check when the leasedb says we don't have a share is more debatable. In principle, this shouldn't affect latency of downloads because the downloader should use the first shares.needed servers that respond positively, so the latency of negative responses shouldn't matter.
