Rich B <[email protected]> writes:
>> Could you give some more context? In particular, I'd like to see the logs
>> from the 32st and 1st retry.
>>
>> Because of log rotations, I had to re-run the test to get the 1st and 32nd
> retry. This time more of the blocks managed to get uploaded. Some of the
> threads seemed to have better luck than others:
[...]
>
> If I manually kill mount.s3ql and umount the filesystem, then run
>> fsck.s3ql, the cache does get uploaded (with some difficulty):
>>
>> $ fsck.s3ql --cachedir /data/s3ql-cache
>> gs://MyBucket/MyPrefix
>>
>>
>> Starting fsck of gs://MyBucket/MyPrefix
>> Using cached metadata.
>> Remote metadata is outdated.
>> Checking DB integrity...
>> Creating temporary extra indices...
>> Checking lost+found...
>> Checking cached objects...
>> Committing block 0 of inode 143 to backend
>> Committing block 0 of inode 289 to backend
>> Committing block 0 of inode 212 to backend
>> Committing block 0 of inode 338 to backend
>> Committing block 0 of inode 334 to backend
>> Committing block 0 of inode 154 to backend
>> Committing block 0 of inode 350 to backend
>> Committing block 0 of inode 354 to backend
>> Committing block 0 of inode 224 to backend
>> Committing block 0 of inode 215 to backend
>> Committing block 0 of inode 221 to backend
>> Committing block 0 of inode 339 to backend
>> Committing block 0 of inode 278 to backend
>> Committing block 0 of inode 178 to backend
>> Encountered ConnectionTimedOut exception (send/recv timeout exceeded),
>> retrying call to ObjectW.close for the 3-th time...
>> Encountered ConnectionTimedOut exception (send/recv timeout exceeded),
>> retrying call to ObjectW.close for the 4-th time...
>> Encountered ConnectionTimedOut exception (send/recv timeout exceeded),
>> retrying call to ObjectW.close for the 5-th time...
>> Encountered ConnectionTimedOut exception (send/recv timeout exceeded),
>> retrying call to ObjectW.close for the 6-th time...
>> Encountered ConnectionTimedOut exception (send/recv timeout exceeded),
>> retrying call to ObjectW.close for the 7-th time...
>> Encountered ConnectionTimedOut exception (send/recv timeout
>> exceeded),
[...]
To me this looks just like a crappy network connection. You could try to
increase the send/recv timeout (using the --backend-options argument,
see manual).
>> I'm stumped. Has anyone got an idea of what might be causing my problem?
>>
>>
>> Do you have the same problem when you store data in Amazon S3 from the
>> same system?
>>
> Yes, I just tried Amazon and I get similar results.
This is consistent with a bad connection.
>> If you have the necessary SSL-fu, you could also do a traffic capture using
>> Wireshark. That's gonna be a bit tricky, but it should tell us a lot more.
>
> I've worked with tcpdump/wireshark before, but my SSL-fu is weak can
> you tell me what I should look for?
I'm afraid not, I never got it to work myself. But you're lucky, if you
have the same problem with S3, just use --backend-options nossl, and
capture that traffic.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
