On Mon, 1 Dec 2014, Nikolaus Rath wrote:
[snip]
I think at this point I can probably write you a patch to get the file
system functional again, but I'd very much like to find out what's
happening here.
Would you be able to run fsck with --backend-options no-ssl, and capture
the traffic using Wireshark?
Hi Nikolaus,
I performed several runs of fsck.s3ql while experimenting with wireshark
(it has been years since I've used it or tcpdump) to get the settings
right. Each time, fsck.s3ql failed in the same manner. Then when I did
what was to be the final run/capture, it ran to completion without
errors.
Given the behavior above, the first thing that leaps to mind is possibly a
race condition. I would usually expect more inconsistency (such as
failing at different objects each time) if it was simply uninitialized
data or corruption, though those may be possibilities too.
I still have the bucket that was copied using the aws command line tools,
and am in the process of copying that to a new bucket for testing so we
don't lose the corrupt version, but won't get to testing it tonight. I
have not tried to use the original file system since fsck.s3ql succeeded
and am not entirely sure if it trust it without knowing what was wrong
with fsck.s3ql
Something more for you to ponder. FWIW.
Regards,
Shannon C. Dealy | DeaTech Research Inc.
de...@deatech.com | - Custom Software Development -
USA Phone: +1 800-467-5820 | - Natural Building Instruction -
numbers : +1 541-929-4089 | www.deatech.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
