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@xxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
