reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: sh@keff.org
Cc: Edward Shishkin <edward.shishkin@gmail.com>,
	reiserfs-devel@vger.kernel.org
Subject: Re: Negative blocks in rebuild-tree
Date: Tue, 11 Jan 2011 14:30:55 -0500	[thread overview]
Message-ID: <4D2CAFEF.8060309@suse.com> (raw)
In-Reply-To: <4D2CAF0F.5070806@keff.org>

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

  reply	other threads:[~2011-01-11 19:30 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 [this message]
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
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=4D2CAFEF.8060309@suse.com \
    --to=jeffm@suse.com \
    --cc=edward.shishkin@gmail.com \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=sh@keff.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).