From: Sebastian Hyrwall <sh@keff.org>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Edward Shishkin <edward.shishkin@gmail.com>,
reiserfs-devel@vger.kernel.org
Subject: Re: Negative blocks in rebuild-tree
Date: Mon, 17 Jan 2011 10:59:08 +0100 [thread overview]
Message-ID: <4D3412EC.10502@keff.org> (raw)
In-Reply-To: <4D2CC5F9.4040208@suse.com>
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
>
>
next prev parent reply other threads:[~2011-01-17 9:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-08 13:31 Negative blocks in rebuild-tree Sebastian Hyrwall
2011-01-09 0:58 ` Edward Shishkin
2011-01-09 2:09 ` Sebastian Hyrwall
2011-01-09 21:40 ` Jeff Mahoney
2011-01-11 19:27 ` sh
2011-01-11 19:30 ` Jeff Mahoney
2011-01-11 19:35 ` sh
2011-01-11 19:42 ` sh
2011-01-11 19:52 ` Jeff Mahoney
2011-01-11 21:04 ` Jeff Mahoney
2011-01-12 9:37 ` Sebastian Hyrwall
2011-01-17 9:59 ` Sebastian Hyrwall [this message]
2011-01-18 22:50 ` Jeff Mahoney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D3412EC.10502@keff.org \
--to=sh@keff.org \
--cc=edward.shishkin@gmail.com \
--cc=jeffm@suse.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).