Marc Tooley wrote: > The ability to actually delete shares, for those of us who are afraid > to run the garbage collector because we're afraid to forget to renew > leases, would be neat in support of features like this sort of > re-balancing. (And perhaps for distant-future human-intervention space > reclamation too.)
Hm, so basically it'd be less scary to delete a single share if you knew that another copy existed elsewhere, like if you'd just done a checker run, or if the protocol involved two servers talking to each other and coordinating the move. The ability to do this without fear would let you rebalance without consuming more space. It wouldn't let you reclaim space for files you've dereferenced. I suppose the relative sizes of these two potential savings would depend upon whether you add servers or delete files more quickly.. something that will be quite different for each user. I suppose one idea to kick around would be define a stronger cap, to distinguish between "read-and-delete-shares" caps and plain "read-and-not-delete-shares" caps. This would be fairly easy to implement if you used non-CHK keys, or if the stronger caps could have an extra cryptovalue. Neither could be used to violate the confidentiality or integrity guarantees of readcaps, but the stronger one could be used to hurt availability (which, of course, cannot be provided by cryptographic means, at least not with the same sort of 2**128 margins that we get out of AES/DSA). I don't know one might make use of this, however: I don't know what would prompt Alice to give Bob the read-and-not-delete-shares cap and keep the read-and-delete-shares cap for herself, versus using a scheme without -and-delete caps. Maybe she doesn't like Bob, and wants to make him live in fear that she's going to delete the shared files that he's linked to? And maybe she has an efficient way to keep track of all of her own files, so she can delete with confidence, so she wants the read-and-delete-shares caps to make the final deletion process easier? Eh, lease-timers still feel like the most usable solution, even if both you and I are afraid to actually turn on expiry :). cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
