On Dec 28 2020, Paul Tirk <[email protected]> wrote:
> Am Mo, 28. Dez, 2020 um 1:41 P. M. schrieb Nikolaus Rath <[email protected]>:
>> On Dec 28 2020, Ivan Shapovalov <[email protected]> wrote:
>>> 2020-12-27 19:04:33.819 211867 DEBUG Thread-1
>>> s3ql.backends.b2.b2_backend._do_request: RESPONSE: POST 400 97
>>> 2020-12-27 19:04:33.820 211867 DEBUG MainThread
>>> s3ql.block_cache.with_event_loop:
>>> upload of 8652 failed
>>> NoneType: None
>>> 2020-12-27 19:04:33.827 211867 DEBUG Thread-1 s3ql.mount.exchook:
>>> recording exception
>>> 400
>>> : bad_request - Checksum did not match data received
>>> zsh: terminated mount.s3ql b2://<mybucket> /mnt/b2/files -o
>>> -- 8< --
>>>
>>> Leaving out the question of why journald eats the last line, the
>>> situation is pretty clear. The backend (B2Backend._do_request) raises
>>> an exception (B2Error) which is not considered a "temporary failure".
>>>
>>> I have just patched up error handling in the B2 backend to consider the
>>> checksum mismatch a transient failure (testing now).
>>
>> Is B2 not using SSL for its data connection? That should make sure that
>> there are no checksum errors....
>>
>
> I think this error refers to B2 not receiving the correct data. When an
> object is
> uploaded, the checksum is provided through a header, B2 then checks the
> received data if
> it has the same checksum as the one provided.
>
> Since this is a case which should not happen (and never happened to me) it
> was not clear
> how to handle it. But probably it would be best to also retry it for some
> time in case it
> is really just temporary..
I think if this is not a result of the network connection flipping some
bits, then it is either a bug in S3QL (perhaps the data is being
modified while uploaded), or a faulty machine on the local side, or a
faulty machine on the receiving side.
I think in all these cases retrying is likely to succeed and will thus
result in the problem not being surfaced. I would, personally, prefer to
know about such issues so that I can replace RAM/disks/CPU, switch
storage providers, or find the S3QL bug *before* something more serious
happens and results in un-fixable corruption.
Best,
-Nikolaus
--
GPG 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/87wnx1g9v7.fsf%40vostro.rath.org.
