[tahoe-dev] dynamic ip

Greg Troxel gdt at ir.bbn.com
Tue Jun 18 12:37:00 UTC 2013


"erpo41 at gmail.com" <erpo41 at gmail.com> writes:

> Not finding the right parameter would result either in an increased
> likelihood of data loss or in upload failures. Either of those is a
> big deal to me, and I suspect it is for most other Tahoe
> friendnet-type users.

When I look at the whole situation, I am pretty unconcerned about a
factor of 2 in efficiency or reliablity.  It feels like you are deciding
that parameters must be optimal for some situation without that being
(what looks like to me) a global optimum situation.  I'm much more
concerned about reasonable behavior over an ensemble of possible future
realitties than efficiency in the happy path.

> I mean, you have to be pretty paranoid if backing up your data to an
> external hard drive and taking it to another building isn't enough.

In theory, tahoe backups will be easier than that.  Schemes involving
moving objects tend to fail by the humans not getting around to it.

> I did not find this to be true. Setting aside the fact that none of my
> uploads ever completed (with the exception of a single, small test
> file),

So something is really wrong here, and it would be interesting to see
what the issues were.

> other participants reported that multiple sequential deep-check
> --repair --add-lease runs would result in repairs being needed, when
> the second and subsequent runs should have been free of errors.

I think that's ticket:1209.

>> True.  I guess I see the N/K overhead as fundamentally built in, and
>> don't worry about it.   If tahoe were to the point that my uplink
>> capacity were limiting, that would be great.
>
> The N/K overhead is not fundamentally built in and can be avoided with
> an upload helper (when considering the amount of data transferred over
> the link between the uploader and the upload helper). And yes, Tahoe
> rarely maxed out my upstream connection too.

It's only avoidable on your uplink, assuming the helper has more
capacity.  But I don't see this (a factor of 3, more or less) as
important; if tahoe were routinely only 3x slower and everything else
were fixed, I'd be very happy with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130618/138c8ebb/attachment.pgp>


More information about the tahoe-dev mailing list