upload difficulty and global tahoe status ?

Freelab initiative freelab.cc at gmail.com
Fri Jul 17 17:01:33 UTC 2015


1

if you have nat issues or if you have slow internet connection
using an helper is the way to follow

just sometimes check that helper is still running and not receinving files
and doing nothing with them.



2

if using the cli, is there a way to make the thing a bit more verbose ?

when starting :  tahoe backup.

it sometimes seems that tahoe get lost somewhere mainly because it gives no
information about the actual process status.



this is true the cli can be a bit more verbose thanks to the commande
--verbose.


but my biggest problem with tahoe backup is that until evything is uploaded
the directory listing keeps being empty
when i upload 100-200 gB i would apreciate to see something before the last
byte is uploaded


am i the only person to feels that being really a weird behavior ?



cordialement,

xavier


2015-07-17 16:31 GMT+02:00 Shu Lin <linshu at gmail.com>:

> Hi Lukas,
>
> Seems Helper is not the key problem.
>
> As we observed, the two key problems are:
>
> 1, Two steps in Tahoe uploading:
>   a, uploading to the server or helper
>   b, encryption, allocating shares and distribution
>
> The web or other frontend only interact with and waiting for the response
> from the first step in http session or sftp session. In the second step the
> frontend is not associated with the backend handling session, so it will
> timeout. Then, this frontend will give a user of feeling upload failure.
> This should be able to solve by using slow operation progress status
> update. The related discussion and article are here.
>
> https://tahoe-lafs.org/pipermail/tahoe-dev/2015-April/009409.html
>
> https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst#slow-operations-progress-and-cancelling
>
> 2, The second problem we have observed is Tahoe crashes sometime in big
> file uploading. But, it seems this problem is also related with #1, if we
> don't have the first failure, we didn't see this crash. We are still
> investigating ...
>
> To solve these problems, I am here borrowing Tahoe's forum to introduce
> you a company, called Sercle.net . We are building our service based on
> Tahoe and adding some key features which normal customers might need, such
> as authentication, key management authorization, and self controlled easy
> deployment. By using our service, you can deploy Tahoe easily by just
> clicking some buttons either in cloud or in premise. We are also providing
> mobile apps for better UI.
>
> The big file uploading is in our road map and we will cooperate with Tahoe
> team to solve it in our service. :-)
>
> Thanks,
> -Shu
>
>
> On Fri, Jul 17, 2015 at 2:01 AM, Lukas Pirl <tahoe-dev at lukas-pirl.de>
> wrote:
>
>> On 07/17/2015 08:30 PM, Freelab initiative wrote:
>> > normally for slow links using a helper with a good connection shall
>> > helps to reduce the traffic pretty much.
>>
>> Thanks replying. I was mainly suffering from #610 and #613:
>> through a helper, I had to upload everything on every `tahoe backup`.
>> I am forced to use a helper, because I have a star topology (storage
>> servers NATed). Snap :)
>>
>> Cheers,
>>
>> Lukas
>> _______________________________________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20150717/161bb06d/attachment.html>


More information about the tahoe-dev mailing list