Bug in reiserfsck 3.6.1-pre1

Bug in reiserfsck 3.6.1-pre1

[Unknown]

Pass 2:

# reiserfsck --rebuild-tree -S /dev/md0

...
0%..rewrite_file: 2 items of file [97373 97385] moved to [97373 1591], 207
/sec
..20%....40%..vpf-10260: The file we are inserting the new item (89 280
0x120001 IND (1), len 4048, location 48 entry count 0, fsck need 0, format
new) into has not StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (89 280 0x514001 IND
(1), len 4048, location 48 entry count 0, fsck need 0, format new) into
has not StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (89 280 0x908001 IND
(1), len 4048, location 48 entry count 0, fsck need 0, format new) into
has not StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (2035 3072665 0x10b001
IND (1), len 1060, location 3036 entry count 0, fsck need 0, format new)
into has not StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (2035 3072665 0x10b001
IND (1), len 1060, location 3036 entry count 0, fsck need 0, format new)
into has not StatData, insertion was skipped
ufile.c 171 delete_N_items_after_key
delete_N_items_after_key: No directory item of [32340 32341] are expected
Aborted

I needed the rebuid because I had a multiple RAID disk death.

I restarted the check; if it dies again I'll append a core dump.

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/

Re: Bug in reiserfsck 3.6.1-pre1

[Manuel Krause]

On 09/16/2002 02:56 AM,
reiserfs-list-return-11456-manuel.krause=mb.tu-ilmenau.de@namesys.com wrote:
> Pass 2:
> 
> # reiserfsck --rebuild-tree -S /dev/md0
> 
> ...
> 0%..rewrite_file: 2 items of file [97373 97385] moved to [97373 1591], 207
> /sec
> ..20%....40%..vpf-10260: The file we are inserting the new item (89 280
> 0x120001 IND (1), len 4048, location 48 entry count 0, fsck need 0, format
> new) into has not StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (89 280 0x514001 IND
> (1), len 4048, location 48 entry count 0, fsck need 0, format new) into
> has not StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (89 280 0x908001 IND
> (1), len 4048, location 48 entry count 0, fsck need 0, format new) into
> has not StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (2035 3072665 0x10b001
> IND (1), len 1060, location 3036 entry count 0, fsck need 0, format new)
> into has not StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (2035 3072665 0x10b001
> IND (1), len 1060, location 3036 entry count 0, fsck need 0, format new)
> into has not StatData, insertion was skipped
> ufile.c 171 delete_N_items_after_key
> delete_N_items_after_key: No directory item of [32340 32341] are expected
> Aborted
> 
> I needed the rebuid because I had a multiple RAID disk death.
> 
> I restarted the check; if it dies again I'll append a core dump.
> 

Can you, please, retry with the latest release of reiserfs-progs

ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.3.tar.gz

or the latest beta

ftp://ftp.namesys.com/pub/reiserfsprogs/pre/reiserfsprogs-3.6.4-pre1.tar.gz

and repost your results.

Thanks,

Manuel

! The first message refers to my personal related return-path in the
! headers officially, I'm not the sender or author of the original
! message. I'll send a different mail to flx@namesys.com as this is a
! definite error. If this is a user error or a problem with my
! browser/mail-app I want a definite hint. And I want the person that
! wrote that first mail to immediately stop writing under my
! return-path!

Re: Bug in reiserfsck 3.6.1-pre1

[Matthias Urlichs]

Hi,

Manuel Krause:
> Can you, please, retry with the latest release of reiserfs-progs
> 
Sorry -- mistyped the release number:
> or the latest beta
> ftp://ftp.namesys.com/pub/reiserfsprogs/pre/reiserfsprogs-3.6.4-pre1.tar.gz
> 
This was the version which I used.

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/

Re: Bug in reiserfsck 3.6.1-pre1

[Oleg Drokin]

Hello!

On Mon, Sep 16, 2002 at 02:56:55AM +0200, reiserfs-list-return-11456-green=namesys.com@namesys.com wrote:

> delete_N_items_after_key: No directory item of [32340 32341] are expected
> Aborted
> I needed the rebuid because I had a multiple RAID disk death.

We are interested in metadata from that volume if possible.
Please run debugreiserfs -p /dev/md0 | gzip -9c >/somewhere/metadata_md0.gz

Then make this file available for us to download.

Thank you.

Bye,
    Oleg

Re: Bug in reiserfsck 3.6.1-pre1

[Matthias Urlichs]

Hi,

Oleg Drokin:
> We are interested in metadata from that volume if possible.
> Please run debugreiserfs -p /dev/md0 | gzip -9c >/somewhere/metadata_md0.gz
> 
Will do, as soon as the save-state re-run from reiserfsck is done and if
it still exhibits the problem.  :-/

> Then make this file available for us to download.
> 
Warning: that'll be 100+ MBytes. Compressed. (The original RAID's almost
half a terabyte.)

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/

Re: Bug in reiserfsck 3.6.1-pre1

[Oleg Drokin]

Hello!

On Mon, Sep 16, 2002 at 09:35:21AM +0200, Matthias Urlichs wrote:

> > Then make this file available for us to download.
> Warning: that'll be 100+ MBytes. Compressed. (The original RAID's almost
> half a terabyte.)

I don't understand where's this number from.
Metadata size exceeds 40 Megabytes pretty rarely.
Yes, I have seen metadata snapshots from 800M filesystems for example.

Bye,
    Oleg

Re: Bug in reiserfsck 3.6.1-pre1

[Matthias Urlichs]

Hi,

Oleg Drokin:
> > Warning: that'll be 100+ MBytes. Compressed. (The original RAID's almost
> > half a terabyte.)
> 
> I don't understand where's this number from.

Don't ask me:

# ls -l /var/tmp/metadata_md0.gz 
-rw-r--r--    1 root     root     100532224 Sep 16 08:41 /var/loctmp/metadata_md0.gz

> Metadata size exceeds 40 Megabytes pretty rarely.

I have approx. a million files on that filesystem. Guess why I am using
reiserfs in the first place?  ;-)

Note that this file system has severely corrupted bitmaps (not to say
everything else -- I basically had to restore every third 4-kByte block
from a month-old copy. :-/ ).

Whether that matters for debugreiserfs's dump size is for you to say.

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/

Re: Bug in reiserfsck 3.6.1-pre1

[Oleg Drokin]

Hello!

On Mon, Sep 16, 2002 at 09:59:00AM +0200, Matthias Urlichs wrote:
> > > Warning: that'll be 100+ MBytes. Compressed. (The original RAID's almost
> > > half a terabyte.)
> > I don't understand where's this number from.
> Don't ask me:
> # ls -l /var/tmp/metadata_md0.gz 
> -rw-r--r--    1 root     root     100532224 Sep 16 08:41 /var/loctmp/metadata_md0.gz

Oh.

> > Metadata size exceeds 40 Megabytes pretty rarely.
> I have approx. a million files on that filesystem. Guess why I am using
> reiserfs in the first place?  ;-)

;)

> Note that this file system has severely corrupted bitmaps (not to say
> everything else -- I basically had to restore every third 4-kByte block
> from a month-old copy. :-/ ).

If you took the snapshot after failed reiserfsck --rebuild-tree, that should
be enough for us to reproduce, so please make metadata available for download
please. 

Thank you.

Bye,
    Oleg

Re: Bug in reiserfsck 3.6.1-pre1

[Matthias Urlichs]

Hi,

Oleg Drokin:
> 
> If you took the snapshot after failed reiserfsck --rebuild-tree, that should
> be enough for us to reproduce, so please make metadata available for download
> please. 
> 
I had to stop the dump (system reboot, unlreated to my failed disk).
My current plan is to run fsck with -d up to the point where it fails, then
generate the dump data and make the results available.

It'll take a bit of time -- I also have to physically move the files from
behind my home ADSL line to the company's backbone server, otherwise you'll spend the whole week trying to download the dump files.  :-/

At the moment fsck is doing this:
[...]
Pass 0 result loaded. 834934 leaves, 66434893/144 good/bad data blocks

Pass 1 (will try to insert 834934 leaves):
####### Pass 1 #######
Looking for allocable blocks .. fininshed
0%is_leaf_bad: block 16723L items 5 and 6: Wrong order of items:7161, 1295 /sec
        41402 41403 0x1 IND (1), len 496, location 500 entry count 0, fsck need 1, format new
        41402 41403 0x7c001 IND (1), len 304, location 196 entry count 65535, fsck need 1, format new
is_leaf_bad: WARNING: The leaf (16723) is formatted badly. Will be handled on the the pass2.
...

... which it'll be busy with during the next half-hour or so.

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/