<p dir="ltr">Dear droki:</p>
<p dir="ltr">Awesome! This might be just the key we need to unlock this.</p>
<p dir="ltr">One possibility would be if you'd be willing to have your node connect to our log-gatherer. Then all of the logs from your node would be transferred (over Foolscap, therefore encrypted) to us.</p>
<p dir="ltr">Regards,</p>
<p dir="ltr">Zooko</p>
<div class="gmail_quote">On Jul 10, 2015 17:39, "droki" <<a href="mailto:droki@riseup.net">droki@riseup.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>><br>
>> I'm having trouble running "tahoe backup" involving two different<br>
>> issues. First, my backup command keeps getting stuck on a single file.<br>
>> It just hangs on the file.<br>
>><br>
>> In fact, this behavior isn't limited to "backup", when I run "tahoe<br>
>> check URI:CHK:..." on the URI in question I get the same result - it<br>
>> just hangs.<br>
><br>
> We're currently diagnosing a similar issue that a couple of users are<br>
> having with the LeastAuthority.com S4 service. Are you using S4? If<br>
> so, you're another S4 user having this problem, and we could use your<br>
> help investigating it. If not, then this is surprising because I<br>
> thought the bug was in the S4 backend, so if you're having this bug<br>
> *without* using the S4 backend, please let us know!<br>
><br>
<br>
Hi Zooko, thanks for your response.<br>
<br>
I am not a LeastAuthority S4 customer, but I am using the S3 storage<br>
backend. Let me know if I can do anything to help diagnose the issue.<br>
<br>
I used 'tahoe debug dump-cap' against the URI:CHK to get the storage<br>
index and found the share that the URI refers to, but I don't know if<br>
there's anything helpful there. Here are the English words that 'cat 0 |<br>
strings' spit out:<br>
<br>
codec_name:3:crs,codec_params:8:5881-1-1,crypttext_hash:32:<br>
,crypttext_root_hash:32:<br>
,needed_shares:1:1,num_segments:1:1,segment_size:4:5881,share_root_hash:32:<br>
,size:4:5881,tail_codec_params:8:5881-1-1,total_shares:1:1,<br>
<br>
Let me know what else I can do to help debug this.<br>
<br>
-droki<br>
<br>
<br>
>> This brings me to my second issue. I was trying to work around this<br>
>> problem and thought "I'll just make a whole new backup."  So I ran<br>
>> "tahoe backup" and specified a new directory as the destination. But I<br>
>> saw that tahoe was still skipping all the files that had previously been<br>
>> backed up, so it wasn't creating  a new complete backup. Is this the<br>
>> intended behavior?<br>
><br>
> Yes, it re-uses the already-uploaded files that are already in the<br>
> Tahoe-LAFS grid. It links to them from the newly created backup. Make<br>
> sense?<br>
><br>
>> And, even when specifying a new destination, the backup command got<br>
>> stuck on the same URI.<br>
><br>
> Same problem as above. If you're an S4 customer, please send email to<br>
> support@LeastAuthority.com. If not, or even if so, please reply to<br>
> this letter to tahoe-dev. :-)<br>
><br>
>> How can I create a totally new backup?<br>
><br>
> I don't think it would help to re-upload the files that are already<br>
> successfully in the grid, but if you want that you could rm the backup<br>
> database and next time you ran "tahoe backup" it would reupload them.<br>
><br>
> (Then they would get de-duped on the server side, so it wouldn't use<br>
> any more server space after upload.)<br>
><br>
><br>
>>  What should I think of this bad URI?<br>
><br>
> Our current hypothesis is that it is a bug in the S4 backend which is<br>
> somehow data-dependent or sticky so that it applies only to certain<br>
> files, but does to with 100% reproducibility after it gets triggered.<br>
> Daira is investigating right now, so stay tuned, or send us<br>
> information about which S4 account is yours and which file of yours<br>
> hangs to help us debug it.<br>
><br>
> Thanks!<br>
<br>
</blockquote></div>