Negative blocks in rebuild-tree

Negative blocks in rebuild-tree

[Sebastian Hyrwall]

Hi

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) -711052258 blocks 
will be read

Does anyone have any idea on how to fix this?

On a 64-bit system.

Sincerely,
Sebastian H

Re: Negative blocks in rebuild-tree

[Edward Shishkin]

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


> 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

Re: Negative blocks in rebuild-tree

[Sebastian Hyrwall]

Hi

On 01/09/11 01:58, 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?
> 

Disk /dev/mapper/a1: 14680.2 GB, 14680197689344 bytes
255 heads, 63 sectors/track, 1784765 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 6815744 bytes
Alignment offset: 520192 bytes
Disk identifier: 0x00000000


> 
>  -711052258 blocks
> 
> 
>> 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.
> 

If you need any more info like debugreiserfs or something let me know.
If not I will try to provide some more info as the fsck progresses,

####### Pass 0 #######
The whole partition (-710934672 blocks) is to be scanned
Skipping 117586 blocks (super block, journal, bitmaps) -711052258 blocks
will be read
0%....                                              left 2936300517,
16334 /sec


First being able to create the filesystem but then finding out later I
can't fsck it hurts :)

I tried going through the code looking for the possibly use of the wrong
data type but it's hard to debug when it takes ~3 days before hitting
the bug.

> 
>>
>> 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
> 

Sincerely,
Sebastian H

Re: Negative blocks in rebuild-tree

[Jeff Mahoney]

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

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

> 
>> 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
> 


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

iEYEARECAAYFAk0qK00ACgkQLPWxlyuTD7KovQCfQdu4rHi1aOgKXPxwAP0+qRZE
aW8AnR/hJd25t/Clg7FOOcTe8Ri7KASD
=oGFm
-----END PGP SIGNATURE-----

Re: Negative blocks in rebuild-tree

[sh]

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.

The coredmp is 1.7GB so I will upload that somewhere soon.. :)


> 
>>> 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
> 
> 
> 

Re: Negative blocks in rebuild-tree

[Jeff Mahoney]

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

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
>>
>>
>>


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

iEYEARECAAYFAk0sr+8ACgkQLPWxlyuTD7ICRgCfYLtogY7h6YJlkAtMAX1Uv9YK
7igAn24tiGUIlDIReyAhbV1ZdcB91PpK
=td9k
-----END PGP SIGNATURE-----

Re: Negative blocks in rebuild-tree

[sh]

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
> 

#0  0x000000000042008b in balance_leaf (tb=0x7fffc3d0f920,
ih=0x7fffc3d0f440, body=0x6c83a0 "\001",
    flag=6870296, zeros_num=1) at do_balan.c:902
        item_pos = <value optimized out>
        sbytes = {-1009715552, 32767}
        pos_in_item = 2
        tbS0 = 0x33
        n = 4361609
        ret_val = 35
        bi = {bi_bh = 0x6dbf98, bi_parent = 0x42044a, bi_position = 3}
        snum = {-1009715552, 32767}
        i = 7111584
#1  do_balance (tb=0x7fffc3d0f920, ih=0x7fffc3d0f440, body=0x6c83a0
"\001", flag=6870296, zeros_num=1)
    at do_balan.c:1135
        child_pos = <value optimized out>
        h = <value optimized out>
        insert_key = {{ih_key = {k2_dir_id = 58896, k2_objectid = 58903,
u = {k2_offset_v1 = {
                  k_offset = 1, k_uniqueness = 268435456}, k2_offset_v2
= {k_offset = 1, k_type = 1}}},
            u = {ih2_free_space = 33696, ih2_entry_count = 33696},
ih2_item_len = 108,
            ih2_item_location = 0, ih_format = 0}, {ih_key = {k2_dir_id
= 3285251744, k2_objectid = 32767,
              u = {k2_offset_v1 = {k_offset = 7192432, k_uniqueness =
0}, k2_offset_v2 = {
                  k_offset = 7192432, k_type = 0}}}, u = {ih2_free_space
= 0, ih2_entry_count = 0},
            ih2_item_len = 0, ih2_item_location = 0, ih_format = 0}}
        insert_ptr = {0x3f4000, 0x41ff50}
#2  0x000000000042a723 in search_by_key (fs=0x6bcd00,
p_s_key=0x7fffc3d0ca30, p_s_search_path=0x49,
    n_stop_level=1413791264) at stree.c:314
        sb = <value optimized out>
        n_block_number = <value optimized out>
        expected_level = 0
        n_block_size = <value optimized out>
        n_retval = <value optimized out>
        __FUNCTION__ = "search_by_key"
#3  0x0000000000000000 in ?? ()
No symbol table info available.


--

Also.. I think (not used to debugging.. ;),

(gdb) list
907               struct item_head * pasted;
908
909               pasted = B_N_PITEM_HEAD (tbS0, item_pos);
910               /* when directory, may be new entry already pasted */
911               if (I_IS_DIRECTORY_ITEM (pasted)) {
912             if ( pos_in_item >= 0 && pos_in_item <=
get_ih_entry_count (pasted) ) {
913                 /* prepare space */
914                 bi.bi_bh = tbS0;
915                 bi.bi_parent = PATH_H_PPARENT (tb->tb_path, 0);
916                 bi.bi_position = PATH_H_POSITION (tb->tb_path, 1);



> 
> 
> 
>>>
>>>>> 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

Re: Negative blocks in rebuild-tree

[sh]

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.


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

Re: Negative blocks in rebuild-tree

[Jeff Mahoney]

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

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.

Yeah, you'd see that from the pass_2 path but this bread is from a
different one. I'll do a review of bread paths to ensure the block
numbers are unsigned. I already found one in search_by_key().

- -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
> 


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

iEYEARECAAYFAk0stQMACgkQLPWxlyuTD7K8IwCgmYh7CVCAedGtV5jY9s0dM7qg
xm0AnRqs4WVHiaFRaMK22H7dw/WZkv1E
=qubH
-----END PGP SIGNATURE-----

Re: Negative blocks in rebuild-tree

[Jeff Mahoney]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

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

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


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

iEYEARECAAYFAk0sxfkACgkQLPWxlyuTD7KlMACfUschi1wXFAGZUXiXSJuF5Z1h
FSMAn1/saYInkC4LdZvZqM74zsqV+1s0
=OM5X
-----END PGP SIGNATURE-----

[-- Attachment #2: signedness-fixes --]
[-- Type: text/plain, Size: 9064 bytes --]

---
 debugreiserfs/debugreiserfs.c |   18 +++++++++---------
 debugreiserfs/pack.c          |   18 +++++++++---------
 debugreiserfs/stat.c          |    2 +-
 fsck/check_tree.c             |    6 +++---
 fsck/pass0.c                  |   10 +++++-----
 fsck/pass1.c                  |    4 ++--
 lib/io.c                      |    2 +-
 reiserfscore/journal.c        |    2 +-
 reiserfscore/reiserfslib.c    |    5 +++--
 reiserfscore/stree.c          |    2 +-
 10 files changed, 35 insertions(+), 34 deletions(-)

--- a/debugreiserfs/debugreiserfs.c
+++ b/debugreiserfs/debugreiserfs.c
@@ -59,11 +59,11 @@ Options:\n\
 
 #if 1
 struct reiserfs_fsstat {
-    int nr_internals;
-    int nr_leaves;
-    int nr_files;
-    int nr_directories;
-    int nr_unformatted;
+    unsigned int nr_internals;
+    unsigned int nr_leaves;
+    unsigned int nr_files;
+    unsigned int nr_directories;
+    unsigned int nr_unformatted;
 } g_stat_info;
 #endif
 
@@ -465,7 +465,7 @@ static void init_bitmap (reiserfs_filsys
     case ALL_BLOCKS:
 	    input_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	    reiserfs_bitmap_fill (input_bitmap (fs));
-	    reiserfs_warning (stderr, "Whole device (%d blocks) is to be scanned\n", 
+	    reiserfs_warning (stderr, "Whole device (%u blocks) is to be scanned\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));	
 	    break;
     case USED_BLOCKS:
@@ -494,7 +494,7 @@ static void init_bitmap (reiserfs_filsys
 		    reiserfs_exit (1, "could not load fitmap from \"%s\"", 
 				   input_bitmap_file_name(fs));
 	    }
-	    reiserfs_warning (stderr, "%d blocks marked in the given bitmap\n",
+	    reiserfs_warning (stderr, "%u blocks marked in the given bitmap\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));
 	    fclose (fp);
 	    break;
@@ -554,8 +554,8 @@ static void do_dump_tree (reiserfs_filsy
 	    }
 
 	    /* print the statistic */
-	    printf ("\t%d internal + %d leaves + %d "
-		    "unformatted nodes = %d blocks\n", 
+	    printf ("\t%u internal + %u leaves + %u "
+		    "unformatted nodes = %u blocks\n",
 		    g_stat_info.nr_internals,   g_stat_info.nr_leaves, 
 		    g_stat_info.nr_unformatted, g_stat_info.nr_internals + 
 		    g_stat_info.nr_leaves + g_stat_info.nr_unformatted);
--- a/debugreiserfs/pack.c
+++ b/debugreiserfs/pack.c
@@ -8,7 +8,7 @@
 
 
 /* counters for each kind of blocks */
-int packed,
+unsigned int packed,
     packed_leaves,
     full_blocks,
     having_ih_array, /* blocks with broken block head */
@@ -638,7 +638,7 @@ static void pack_frozen_data (reiserfs_f
     }
     reiserfs_warning (stderr, "ok\n");fflush (stderr);
     reiserfs_warning (stderr, 
-		      "Super block, bitmaps, journal - %d blocks - done, %d blocks left\n",
+		      "Super block, bitmaps, journal - %u blocks - done, %u blocks left\n",
 		      packed, reiserfs_bitmap_ones (what_to_pack));
 }
 
@@ -693,13 +693,13 @@ void pack_partition (reiserfs_filsys_t *
     magic16 = END_MAGIC;
     fwrite_le16 (&magic16);
 
-    fprintf (stderr, "\nPacked %d blocks:\n"
-	     "\tcompessed %d\n"
-	     "\tfull blocks %d\n"
-	     "\t\tleaves with broken block head %d\n"
-	     "\t\tcorrupted leaves %d\n"
-	     "\t\tinternals %d\n"
-	     "\t\tdescriptors %d\n",
+    fprintf (stderr, "\nPacked %u blocks:\n"
+	     "\tcompessed %u\n"
+	     "\tfull blocks %u\n"
+	     "\t\tleaves with broken block head %u\n"
+	     "\t\tcorrupted leaves %u\n"
+	     "\t\tinternals %u\n"
+	     "\t\tdescriptors %u\n",
 	     packed,
 	     packed_leaves, full_blocks, having_ih_array,
 	     bad_leaves, internals, descs);
--- a/debugreiserfs/stat.c
+++ b/debugreiserfs/stat.c
@@ -245,7 +245,7 @@ void do_stat (reiserfs_filsys_t * fs)
 	reiserfs_exit (1, "could not open %s to save bitmap: %m\n",
 		       input_bitmap_file_name(fs));
     }
-    reiserfs_warning (stderr, "Updated bitmap contains %d blocks marked\n",
+    reiserfs_warning (stderr, "Updated bitmap contains %u blocks marked\n",
 		      reiserfs_bitmap_ones (input_bitmap (fs)));
     
     reiserfs_bitmap_save (fp, input_bitmap (fs));
--- a/fsck/check_tree.c
+++ b/fsck/check_tree.c
@@ -119,7 +119,7 @@ static int is_block_free (reiserfs_filsy
 }
 
 
-/*static int hits = 0;*/
+/*static unsigned int hits = 0;*/
 
 /* we have seen this block in the tree, mark corresponding bit in the
    control bitmap */
@@ -156,7 +156,7 @@ static void init_control_bitmap (reiserf
     for (i = 0; i <= fs->fs_super_bh->b_blocknr; i ++)
     	we_met_it (i);
 
-    /*printf ("SKIPPED: %d blocks marked used (%d)\n", hits, 
+    /*printf ("SKIPPED: %u blocks marked used (%d)\n", hits,
               reiserfs_bitmap_zeros (control_bitmap));
       hits = 0;*/
 
@@ -172,7 +172,7 @@ static void init_control_bitmap (reiserf
 	    block ++;	
     }
     
-    /*printf ("BITMAPS: %d blocks marked used (%d)\n", hits, 
+    /*printf ("BITMAPS: %u blocks marked used (%d)\n", hits,
 	      reiserfs_bitmap_zeros (control_bitmap));
 	      
       hits = 0;*/
--- a/fsck/pass0.c
+++ b/fsck/pass0.c
@@ -1759,7 +1759,7 @@ static void init_source_bitmap (reiserfs
     case ALL_BLOCKS:
 	fsck_source_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	reiserfs_bitmap_fill (fsck_source_bitmap (fs));
-	fsck_progress ("The whole partition (%d blocks) is to be scanned\n", 
+	fsck_progress ("The whole partition (%u blocks) is to be scanned\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));	
 	break;
 
@@ -1768,7 +1768,7 @@ static void init_source_bitmap (reiserfs
 	fsck_source_bitmap (fs) = reiserfs_create_bitmap (block_count);	
 	reiserfs_bitmap_copy (fsck_source_bitmap (fs), fs->fs_bitmap2);
 	
-	fsck_progress ("ok, %d blocks marked used\n", 
+	fsck_progress ("ok, %u blocks marked used\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));
 	break;
 
@@ -1787,7 +1787,7 @@ static void init_source_bitmap (reiserfs
 			   fsck_data (fs)->rebuild.bitmap_file_name);
 	}
 
-	fsck_progress ("%d blocks marked used in extern bitmap\n", 
+	fsck_progress ("%u blocks marked used in extern bitmap\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));
 	fclose (fp);
 	break;
@@ -1863,8 +1863,8 @@ static void init_source_bitmap (reiserfs
 
     fsck_source_bitmap (fs)->bm_set_bits = reiserfs_bitmap_ones (fsck_source_bitmap (fs));
 
-    fsck_progress ("Skipping %d blocks (super block, journal, "
-		   "bitmaps) %d blocks will be read\n", tmp, fsck_source_bitmap (fs)->bm_set_bits);
+    fsck_progress ("Skipping %u blocks (super block, journal, "
+		   "bitmaps) %u blocks will be read\n", tmp, fsck_source_bitmap (fs)->bm_set_bits);
 		
 }
 
--- a/fsck/pass1.c
+++ b/fsck/pass1.c
@@ -646,8 +646,8 @@ void load_pass_1_result (FILE * fp, reis
     fetch_objectid_map (proper_id_map (fs), fs);
     */
 
-    fsck_progress ("Pass 1 result loaded. %d blocks used, %d allocable, "
-		   "still to be inserted %d\n",
+    fsck_progress ("Pass 1 result loaded. %u blocks used, %u allocable, "
+		   "still to be inserted %u\n",
 		   reiserfs_bitmap_ones (fsck_new_bitmap (fs)),
 		   reiserfs_bitmap_zeros (fsck_allocable_bitmap (fs)),
 		   reiserfs_bitmap_zeros (fsck_uninsertables (fs)));
--- a/lib/io.c
+++ b/lib/io.c
@@ -628,7 +628,7 @@ void close_rollback_file () {
             return;
         fwrite (&rollback_blocks_number, sizeof (rollback_blocksize), 1, s_rollback_file);
         if (log_file != 0) 
-            fprintf (log_file, "rollback: %d blocks backed up\n", rollback_blocks_number);
+            fprintf (log_file, "rollback: %u blocks backed up\n", rollback_blocks_number);
     }
         
     fclose (s_rollback_file);
--- a/reiserfscore/journal.c
+++ b/reiserfscore/journal.c
@@ -577,7 +577,7 @@ int reiserfs_create_journal(
 	{
 	    /* host device does not contain enough blocks */
 	    reiserfs_warning (stderr, "reiserfs_create_journal: cannot create "
-		"a journal of %lu blocks with %lu offset on %d blocks\n", 
+		"a journal of %lu blocks with %lu offset on %u blocks\n",
 		len, offset, get_sb_block_count(sb));
 		return 0;
 	}
--- a/reiserfscore/reiserfslib.c
+++ b/reiserfscore/reiserfslib.c
@@ -59,7 +59,8 @@ reiserfs_filsys_t * reiserfs_open (char
     reiserfs_filsys_t * fs;
     struct buffer_head * bh;
     struct reiserfs_super_block * sb;
-    int fd, i;
+    int fd;
+    unsigned int i;
 
     /* convert root dir key and parent root dir key to little endian format */
     make_const_keys ();
@@ -200,7 +201,7 @@ reiserfs_filsys_t * reiserfs_create (cha
 	block_size, block_count, 0)) 
     {
 	reiserfs_warning (stderr, "reiserfs_create: can not create that small "
-	    "(%d blocks) filesystem\n", block_count);
+	    "(%u blocks) filesystem\n", block_count);
 	return 0;
     }
 
--- a/reiserfscore/stree.c
+++ b/reiserfscore/stree.c
@@ -313,7 +313,7 @@ int search_by_key (reiserfs_filsys_t * f
 		   int  n_stop_level)   /* How far down the tree to search.*/
 {
     struct reiserfs_super_block * sb;
-    int n_block_number,
+    unsigned int n_block_number,
 	expected_level,
 	n_block_size    = fs->fs_blocksize;
     struct buffer_head  *       p_s_bh;

Re: Negative blocks in rebuild-tree

[Sebastian Hyrwall]

Hi

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

Thanks. Running.... see you in 4 days :)


> 
> 
>> 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
> 
> 

Re: Negative blocks in rebuild-tree

[Sebastian Hyrwall]

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! ;)

/ 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
> 
> 

Re: Negative blocks in rebuild-tree

[Jeff Mahoney]

-----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-----