Re: Negative blocks in rebuild-tree

[Jeff Mahoney <jeffm@suse.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/17/2011 04:59 AM, Sebastian Hyrwall wrote:
> Hi
> 
> That did it! Took like a week to finish but now it's done and everything
> looks good.
> 
> I'm extremely thankful!
> 
> Commit the patch! ;)

Great, thanks for testing and for the feedback.

- -Jeff

> / Sebastian H
> 
> 
> On 01/11/11 22:04, Jeff Mahoney wrote:
>> On 01/11/2011 02:42 PM, sh@keff.org wrote:
>>> Hmm. I don't think this is the same error I got the first time. Then it
>>> was something like '("pass_2: Reading of the block (%lu) failed on the
>>> device 0x%x\n"' (pass2.c).
>>
>>> Then I didn't run the fsck with -S.
>>
>> Can you try to reproduce with the attached patch? Most of it are
>> formatting changes so the negative blocks (printed) will go away but
>> there are two signedness fixes in there that should help.
>>
>> -Jeff
>>
>>
>>> On 01/11/11 20:30, Jeff Mahoney wrote:
>>>> On 01/11/2011 02:27 PM, sh@keff.org wrote:
>>>>> Hi
>>>>
>>>>> On 01/09/11 22:40, Jeff Mahoney wrote:
>>>>>> On 01/08/2011 07:58 PM, Edward Shishkin wrote:
>>>>>>> On 01/08/2011 02:31 PM, Sebastian Hyrwall wrote:
>>>>>>>> Hi
>>>>>>
>>>>>>> Hello.
>>>>>>
>>>>>>>>
>>>>>>>> I am getting a negative block-number with reiserfsck when doing
>>>>>>>> --rebuild-tree -S (or without -S). This causes a segmentation fault
>>>>>>>> later (pass 2) in the check because it tries to read a "non-existant
>>>>>>>> block". My rebuild takes 3 days and i didn't copy the stdout-info the
>>>>>>>> first time so I will post some more info as soon as it becomes available.
>>>>>>>>
>>>>>>>> Pass 0:
>>>>>>>> ####### Pass 0 #######
>>>>>>>> The whole partition (-710934672 blocks) is to be scanned
>>>>>>>> Skipping 117586 blocks (super block, journal, bitmaps)
>>>>>>
>>>>>>
>>>>>>> So you do have a ~16T partition. Correct?
>>>>>>
>>>>>>
>>>>>>>  -711052258 blocks
>>>>>>
>>>>>> This bit isn't bad typing - it's bad printf formatting. The actual bad
>>>>>> typing is going to be harder to track down. A quick look showed me some
>>>>>> signed block count variables in the debugreiserfs code but the fsck code
>>>>>> may be better off. I'll dig into it.
>>>>>>
>>>>>> Since you're trying to reproduce, it would be great if you capture the
>>>>>> core dump that should happen when you seg fault. Exact output would be
>>>>>> useful as well.
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>> Pass 1 (will try to insert 3472246 leaves):
>>>>> ####### Pass 1 #######
>>>>> Looking for allocable blocks .. finished
>>>>> 0%....20%^[[A....40%....60%..bc ..80%....100%
>>>>> left 0, 62 /sec
>>>>> Flushing..finished
>>>>>         3472246 leaves read
>>>>>                 3457984 inserted
>>>>>                         - pointers in indirect items pointing to
>>>>> metadata 77 (zeroed)
>>>>>                 14262 not inserted
>>>>>         non-unique pointers in indirect items (zeroed) 71213
>>>>> ####### Pass 2 #######
>>>>
>>>>> Pass 2:
>>>>> 0%bread: Cannot read the block (18446744072169358012): (Invalid
>>>>> argument). /sec
>>>>> bread: Cannot read the block (18446744072169358012): (Invalid argument).
>>>>
>>>>> gdb
>>>>
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x000000000042008b in ?? ()
>>>>
>>>>> ---
>>>>> 18446744072169358012 is pretty close to an unsigned int64.
>>>>
>>>> This looks like a signed int got sign extended to a long.
>>>>
>>>>> The coredmp is 1.7GB so I will upload that somewhere soon.. :)
>>>>
>>>> I don't need the whole core dump for now. Can you load up gdb and do:
>>>>
>>>> gdb reiserfsck core
>>>>
>>>> (gdb) bt -full
>>>>
>>>> .. and send the results?
>>>>
>>>> Thanks.
>>>>
>>>> -Jeff
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>>> will be read
>>>>>>>>
>>>>>>>> Does anyone have any idea on how to fix this?
>>>>>>>>
>>>>>>>> On a 64-bit system.
>>>>>>
>>>>>>
>>>>>>> It looks like you have encountered an overflow/truncation fsck bug
>>>>>>> specific to giant volumes.
>>>>>>
>>>>>>> I would first ask Jeff: AFAIK he is planning to enable 16T files
>>>>>>> in reiserfs.
>>>>>>> Jeff, do you have any non-published fixups for such problems?
>>>>>>
>>>>>>> Thanks,
>>>>>>> Edward.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Sincerely,
>>>>>>>> Sebastian H
>>>>>>>> -- 
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> reiserfs-devel" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk02GU4ACgkQLPWxlyuTD7J3YwCgiuQU0petGYirjiAYHanfp2Nx
3NMAoJ/lvVUSFN+/RiZY3P4t9HjAsouY
=DbIi
-----END PGP SIGNATURE-----