GSoC Update - Week 7

For the past couple of weeks I have been writing patches for servers-of-happiness and issues in the command line interface (cli).

• Ticket #1057 (Github) - Alter mutable files to use servers-of-happiness: Tahoe uses the servers-of-happiness measurement for immutable files, but not mutable files. Instead mutable files use the old shares-of-happiness test, which has no concern for share distribution over multiple servers. This behavior is confusing for users because mutable uploads can succeed when it is impossible to upload immutable files. Closing this ticket will improve tahoe's usability as well as increase file redundancy for successful uploads. It is also required before I can implement the upload strategy of happiness for mutable files.
• Ticket #2034 (Github) - Mutable file upload is sensitive to the number of servers: When developing a patch for #1057, I found a small issue in tahoe's mutable upload process. If the number of servers on the grid is greater than k + N, the query process can end prematurely due to a race condition and this will cause tahoe to incorrectly report a file unhealthy. The race condition is unlikely to appear in production because it requires little to no lag between the server query and the response, but it causes issues when testing servers of happiness with mutable files.
• Ticket #2027 (Github) - Inconsistent "tahoe cp" behavior: In tahoe 1.10, there is a small bug in the cli that prevents users from copying a file off of the grid without specifying a file name. The bug is caused by a unicode assertion, so my patch simply converts the destination to unicode.
• Ticket #712 (Github) - Tahoe cp -r doesn't copy the parent: When using the cli, "tahoe cp" is supposed to mimic the behavior of "cp". However, when tahoe copies a directory recursively, it does not copy the parent directory like cp does. My patches fixes this small issue by creating a different target directory for the cli.
• Ticket #1836 (Github) - Use leasedb for share count: Right now tahoe uses a crawler to keep track of share information. This is ineffective, especially for large servers, so there is a branch in development to keep track of share information in a sqlite database. My patch removes the crawler and makes the necessary sql queries instead. Currently the branch cannot be merged with trunk because of a significant performance regression, but the core dev team has slowly been finding the bugs. I'm interested in this branch because I would really like tahoe to have a maximum size limit again.

I was also able to finish the new IRC bot for #tahoe-lafs on freenode during my free time and it has been working out great. The new bot will parse multiple ticket numbers and it will post updates from trac. You can find the source code here, and I've spun the IRC code out into another package that you can find here.