> This sounds more plausible.. we've historically had problems with silently-
> disconnected TCP sessions (either caused by NAT table entries being
> dropped or laptops being closed). There are tahoe.cfg options to turn on
> keepalives ([node]timeout.keepalive and .disconnect), but the default
> ta
Having read Zooko's original message more carefully, I think I was
responding to the wrong concern (which is probably why I deferred
sending that response for long enough to forget about it). Here's a
better response.
On 9/24/10 12:36 AM, Zooko O'Whielacronx wrote:
> However, I'm also sure that
On Fri, Mar 25, 2011 at 11:52 AM, Brian Warner wrote
>
> Whoa. I guess I wrote that message back in October and never sent it..
> must have hit the wrong button this morning and it went out. Sorry for
> the anachronistic confusion!
I'm really glad you posted it! Scaling up Tahoe-LAFS grids is an
On 10/8/10 5:09 PM, Brian Warner wrote:
> On 9/24/10 12:36 AM, Zooko O'Whielacronx wrote:
Whoa. I guess I wrote that message back in October and never sent it..
must have hit the wrong button this morning and it went out. Sorry for
the anachronistic confusion!
-Brian
On 10/5/10 4:47 PM, Greg Troxel wrote:
> I have two theories:
>
> A) I ran 'find . -size +8192 | xargs rm' in the storage area on some
> nodes to reclaim space so I could repair 1 KB files. I don't think I
> did this on linuxpal, as it still has lots free, and I think the ones
> I did it
On 9/24/10 12:36 AM, Zooko O'Whielacronx wrote:
>
> The largest Tahoe-LAFS grid that has ever existed as far as I know was
> the allmydata.com grid. It had about 200 storage servers, where each
> one was a userspace process which had exclusive access to one spinning
> disk. Each disk was 1.0 TB ex
