[tahoe-dev] report from Tahoe-LAFS Weekly Dev Chat 2013-07-04

[Zooko Wilcox-OHearn]

in attendance: Oleksandr, Zooko (scribe), Mark_B, Amber

Agenda: Mark_B's Google Summer of Code

First we looked at the last remaining test failure that happens on
Mark's #1382 branch. The test failure is in test_each_byte ¹, when it
is supposed to be corrupting the ciphertext hash tree. Mark_B's
changes changed the corrupted share from share-num 0 to share-num 2,
although this test really shouldn't be sensitive to *which* share-num
was being corrupted. We began to suspect that the offsets in
"need_4th_victims" might be incorrect with respect to the layout
specified in src/allmydata/immutable/layout.py ², but we stopped
before confirming that. Mark is going to email Brian (the primary
author of that test) and ask for help.

I drew a picture on my whiteboard of the file/segment/block/share
layout. It would be great if we had a proper .svg diagram of this for
our docs. Someone who is handy with Inkscape, please help us out! See
attached photo of my whiteboard.

Then we talked about what else Mark should work on, since he is mostly
done with his original GSoC project (☺!). I asked what he was
interested in. He suggested background migration of shares off of a
drive that indicated it was failing. I suggested instead #568. I don't
know Mark well enough to tell if he was motivated or demotivated by my
explanation of why #568 is important.

I asked what else he might be interested in, and he suggested being
able to configure your storage server to use no more than a certain
maximum amount of space. This is ticket #671 — "sizelimit". Now, it
turns out that #671 could be easily implemented using the new leasedb.
Implementing sizelimit with leasedb is the topic of ticket #1836. But,
leasedb is not integrated into trunk yet. Merging leasedb into trunk
is #1818, which has apparently been superceded by "merging leasedb and
cloud backend both intro trunk", which is #1819.

I emphasized to Mark that Daira, Brian, and me were all very keen on
getting leasedb merged into trunk and would be very grateful if he
would do it, or at least take a stab at it and report back how it
went.

We talked about how next week we might try to have Weekly Dev Chat on
Tuesday or Wednesday morning instead of Thursday morning.

The End

Signed, Zooko the Scribe


footnotes:

¹ https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/test/test_download.py?annotate=blame&rev=3d771132a843a85578dc23a6cac55b4fae09fc64#L945

² https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/layout.py?annotate=blame&rev=3668cb3d068b7f3a56cc88e7c45d4f81c0b4f499#L27

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/568# make immutable
check/verify/repair and mutable check/verify work given only a verify
cap

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/671# bring back
sizelimit (i.e. max consumed, not min free)

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382# immutable peer
selection refactoring and enhancements

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1818# leasedb: track
leases in a sqlite database, not inside shares

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1819# cloud backend:
merge to trunk

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1836# use leasedb (not
crawler) to figure out how many shares you have and how many bytes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2013-07-04-173006.jpg
Type: image/jpeg
Size: 99398 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130704/15b0f4f9/attachment-0001.jpg>