On 12/01/2014 02:04 AM, Shannon Dealy wrote:
> On Sun, 30 Nov 2014, Nikolaus Rath wrote:
>
>> On 11/30/2014 07:07 PM, Nikolaus Rath wrote:
>>> On 11/30/2014 01:07 AM, Shannon Dealy wrote:
>>>>
>>>> Attached is the object_list.txt file from running fsck using your
>>>> patch.
>>>>
>>>> Seems a little peculiar that the exception occurs at the 100000 object
>>>> mark, though it may simply be chance and mean nothing:
>>>>
>>>> "..processed 100000 objects so far.."
>>>
>>> That does not make sense to me. The file that you attached has only
>>> 99540 lines.
>>>
>>> As far as I can tell, there is no way for the above message to be
>>> emitted before 100000 lines have been written to the file.
>>>
>>> Could you post the complete output of fsck.s3ql again, just to be sure?
>
> It is in fact happening that way, however, since it only updates in
> increments of 500, if this is a bug, it is effectively an "off by one"
> error.
Well, not really. It just prints the current status *every 500* objects,
so it really can't be off by 500.
The only explanation that I have is that for some reason Python did not
flush the file system buffer cache when it encountered the exception, so
we're just seeing part of the while. But that really should happen
automatically.
>> If it really is failing with this message, please try the attached
>> patch, run fsck.s3ql with "--debug-modules s3ql.fsck" and attach
>> ~/.s3ql/fsck.log* (depending on the bucket size, there may be several
>> log files).
>
> It maxed out your log file limit (see attached .tgz file), but this was
> interesting as it occurs at the point of the exception:
>
> i=100000, obj_name=s3ql_data_1, obj_id=1
>
> since the previous object was object_id=190092, following the pattern of
> object listing, the above obj_id should probably be 190093 not 1.
Not necessarily 190093, but probably not 1 (because that should have
been the first object, but unfortunately that's missing from the logs).
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?
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.«
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
