I should be able to make it.<div><br></div><div>Mark Berger<br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 1:18 PM, Zooko O'Whielacronx <span dir="ltr"><<a href="mailto:zookog@gmail.com" target="_blank">zookog@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Mark:<br>
<br>
Yay! Good proposal! I'm excited about the prospect of getting some<br>
focused work on improving repair and rebalancing. There are a lot of<br>
different ways that the functionality could be improved.<br>
<br>
I'm not sure, but I have the _feeling_ that the #1382 that Kevan<br>
Carstensen started may be sort of a critical basis for successful work<br>
on related tickets. See his github branch for the code he's written:<br>
<a href="https://github.com/isnotajoke/tahoe-lafs/commits/ticket1382" target="_blank">https://github.com/isnotajoke/tahoe-lafs/commits/ticket1382</a><br>
<br>
Kevan: do you think Mark could profitably work on other repair and<br>
rebalancing tickets while leaving your #1382 branch alone? Or do the<br>
two of you, Kevan and Mark, think it might be a good idea to have Mark<br>
take over Kevan's branch and finish it?<br>
<br>
<a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382#" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382#</a> immutable peer<br>
selection refactoring and enhancements<br>
<br>
Mark, would you be able to attend the coming Tahoe-LAFS Weekly Dev<br>
Chat on Thursday at 15:30Z (8:30am Pacific)?<br>
<br>
<a href="https://tahoe-lafs.org/trac/tahoe-lafs/wiki/WeeklyMeeting" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/wiki/WeeklyMeeting</a><br>
<br>
Regards,<br>
<br>
Zooko<br>
<div><div class="h5"><br>
On Sun, Apr 21, 2013 at 6:17 PM, Mark Berger <<a href="mailto:mjberger@stanford.edu">mjberger@stanford.edu</a>> wrote:<br>
> Hi everyone, over the last few days I have been working on a proposal for<br>
> GSoC to address share rebalancing and repair. I've copied the proposal below<br>
> (with some of my personal contact information redacted :] ). If you see<br>
> something wrong in my proposal, have any questions, or have any suggestions,<br>
> please let me know.<br>
><br>
> Thanks!<br>
> Mark Berger<br>
><br>
><br>
><br>
> Organization: Tahoe-LAFS<br>
> =============<br>
><br>
> Student Info:<br>
> =============<br>
> Mark J. Berger<br>
> Time Zone: Pacific<br>
> Time Zone during GSoC: Eastern<br>
> IRC Handle: <a href="mailto:Mark_B@irc.freenode.net">Mark_B@irc.freenode.net</a><br>
> Github: markberger<br>
> Email: mjberger [at] <a href="http://stanford.edu" target="_blank">stanford.edu</a><br>
><br>
> University Info:<br>
> ================<br>
> University: Stanford University<br>
> Major: Computer Science<br>
> Current Year: Freshman<br>
> Expected Graduation: June 2016<br>
> Degree: BS<br>
><br>
> About Me:<br>
> =========<br>
><br>
> I'm a freshman at Stanford University studying computer science. Right now<br>
> I am finishing up my core requirements and will be pursuing the artificial<br>
> intelligence track or the systems track within the major. My interests lie<br>
> in machine learning, large distributed systems, and web applications.<br>
><br>
> I began programming during an internship at Four Directions Productions in<br>
> 2011, where I learned how to use Python in conjunction with Maya. The<br>
> majority of my college coursework has been in C or C++ on linux with a<br>
> little Java. This has made me familiar with tools such as GCC, GDB and<br>
> Valgrind.<br>
><br>
> While I have never contributed to an open source project before, I am<br>
> making an effort to learn about Tahoe-LAFS and become familiar with its<br>
> code base and community. Using a virtual machine, I've successfully<br>
> installed Tahoe on an Ubuntu server and connected to the Public Test Grid.<br>
> I've also subscribed to the mailing list, connected to the IRC channel, and<br>
> successfully pulled the code off of Github. While I know my lack of<br>
> experience in open source is a short coming, I am completely dedicated to<br>
> using GSoC's Community Bonding Period to overcome any obstacles before the<br>
> official coding period begins.<br>
><br>
><br>
> Project Title: Share Rebalancing and Repair in Tahoe-LAFS<br>
> =========================================================<br>
><br>
> Abstract:<br>
> =========<br>
><br>
> The "servers of happiness" algorithm has improved Tahoe's ability to<br>
> maximize redundancy by ensuring a given subset of all shares are placed on<br>
> distinct nodes. However, this processes is not used to upload mutable<br>
> files, instead opting for the old "shares of happiness" algorithm, which<br>
> has well documented downsides. Additionally, file repair does not<br>
> necessarily  redistribute files to new servers when nodes have been added.<br>
> This creates issues in terms of redundancy and long term server health.<br>
> Implementing proper file rebalancing for all file types during file upload,<br>
> modification, and repair will enhance the reliability of the Tahoe system<br>
> and take full advantage of erasure encoding.<br>
><br>
><br>
> Deliverables:<br>
> =============<br>
><br>
> 1. Mutable files automatically distribute over nodes according to the<br>
> "servers of happiness" algorithm whenever uploaded, modified, or repaired<br>
> (ticket #232).<br>
><br>
> 2. Repair will redistribute files according to "servers of happiness"<br>
> algorithm and only renew the appropriate leases (ticket #699).<br>
><br>
> 3. Documentation changed to correctly reflect the new feature set<br>
><br>
> 4. Create a test suite to be used on a network of virtual machines in order<br>
> to test file rebalancing.<br>
><br>
><br>
> Time Line:<br>
> ==========<br>
><br>
> Note: I would like to have a code review session with my mentor on a weekly<br>
> basis at minimum, especially at the beginning of the program. Those sessions<br>
> are<br>
> left off the time line to avoid redundancy<br>
><br>
> May 27th - June 17th (Community Bonding):<br>
> -----------------------------------------<br>
><br>
> - Remain available via IRC and email<br>
> - Closely follow the development email list<br>
> - Isolate and understand the classes which pertain to the current<br>
>  implementations of the servers of happiness algorithm to determine which<br>
>  parts can be reused.<br>
> - Discuss with my mentor(s) and the community to determine whether code<br>
>  should be refactored to apply to both immutable and mutable files or if<br>
>  the two need to remain distinct for design reasons<br>
> - Discuss with my mentor(s) and the community the best way to go about<br>
> testing<br>
>  file rebalancing.<br>
><br>
> Note: June 3rd through the 14th is my final exams period and I will be<br>
> packing<br>
> so that I can go home to Upstate NY. Since I will be very busy during this<br>
> time, not all of the above may be accomplished in time to start coding.<br>
> My classes do not resume until the end of September 23rd, so I can push my<br>
> time line back a week or two if need be.<br>
><br>
><br>
> Jun 17th - 28th<br>
> ---------------<br>
> - Implement "servers of happiness" for mutable files during the initial<br>
>  file upload and file modification<br>
><br>
> Jul 1st - 12th<br>
> --------------<br>
> - Throughly document code<br>
> - Write test scripts for larger networks<br>
> - Test code using virtual machines or predetermined test scheme from CBP<br>
><br>
> Jul 15th - 19th<br>
> ---------------<br>
> - Clean up test scripts<br>
> - Throughly document test scripts<br>
> - Fix minor bugs<br>
> - Continue to consider and test edge cases<br>
><br>
> Note: "Servers of happiness" for mutable files should be in a mergable state<br>
>       with tests before the midway point on July 29th.<br>
><br>
> Jul 22nd - Aug 2<br>
> ----------------<br>
><br>
> - Modify repair code to use the "server of happiness" algorithm for both<br>
>  immutable and mutable files. This should be accomplished by utilizing the<br>
>  existing code from the initial upload process<br>
><br>
> - Edit mechanism for lease renewal to ensure minimal amount of lease<br>
>  renewal is done during rebalancing<br>
><br>
> Aug 5th - 16th<br>
> --------------<br>
><br>
> - Throughly document code<br>
> - Extend tests for mutable files to encompass rebalancing during file repair<br>
><br>
> Aug 19th - 23rd<br>
> ---------------<br>
><br>
> - Clean up test scripts<br>
> - Throughly document test scripts<br>
> - Fix minor bugs<br>
> - Continue to consider and test edge cases<br>
><br>
> Aug 26th - 30th<br>
> ---------------<br>
><br>
> - Change documentation to reflect additional features<br>
><br>
><br>
> The weeks of September 1st and 8th are left blank for flexibility.<br>
><br>
><br>
> Possible projects if the above are accomplished ahead of schedule:<br>
> ==================================================================<br>
><br>
>  - Detect if disk(s) on a server are in a near fail state. If the disk(s)<br>
>    are close to failing, notify the administrator, and slowly begin<br>
>    redistributing shares to the other storage nodes (tickets #481 and #864).<br>
><br>
>  - Let the user specify a maximum storage capacity for a given storage node<br>
>    based on folder size instead of free space left on the machine.<br>
><br>
>  - Tahoe backend for Google Drive (ticket #1831).<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> tahoe-dev mailing list<br>
> <a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
> <a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
><br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div><br></div>