Re: reiserfsck failure

Re: reiserfsck failure

[Bill Schrier]

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

Resending with smaller attachments

Bill Schrier wrote:

> I am sending along both the --logfile and the core file from a recent
> reiserfsck we were running on our Redhat 7.2 raidzone machine.
>
> During the reiserfsck run, one of the Raid5 drives failed and attempted
> to how swap.  At some point, the entire system locked up, and had to be
> hard booted before it would respond.  After booting, we resynced the
> Raid5 hot spare and restarted the reiserfsck which is still running
> (started Sunday Jan 12 approx 18:30).
>
> If these files provide any information, please pass it along back to us.
>
> Many thanks!
>
> Bill
>
> --
> William J. Schrier              Phone: 412.968.5780 x151
> Neolinear, Inc.                 Fax:   412.968.5788
> 583 Epsilon Drive               Email: wschrier@neolinear.com
> Pittsburgh, PA  15238

[-- Attachment #2: neolinear.reiserfsck.tar.gz --]
[-- Type: application/x-gzip, Size: 14972 bytes --]

Re: reiserfsck failure

[Oleg Drokin]

Hello!

On Tue, Jan 14, 2003 at 04:01:42PM -0500, Bill Schrier wrote:

> > I am sending along both the --logfile and the core file from a recent
> > reiserfsck we were running on our Redhat 7.2 raidzone machine.

Can you say what exact version was that?
Also just before dumping core it should have output some more info on stderr
about assertion failure, we are interested in that message too.

Thank you.

Bye,
    Oleg

Re: reiserfsck failure

[Bill Schrier]

Unfortunatly, the console was completely hosed up and I couldn't even get any
display on it to record any messages to stderr.  Sorry - don't think I can help
there...

Bill

Oleg Drokin wrote:

> Hello!
>
> On Tue, Jan 14, 2003 at 04:01:42PM -0500, Bill Schrier wrote:
>
> > > I am sending along both the --logfile and the core file from a recent
> > > reiserfsck we were running on our Redhat 7.2 raidzone machine.
>
> Can you say what exact version was that?
> Also just before dumping core it should have output some more info on stderr
> about assertion failure, we are interested in that message too.
>
> Thank you.
>
> Bye,
>     Oleg

--
William J. Schrier              Phone: 412.968.5780 x151
Neolinear, Inc.                 Fax:   412.968.5788
583 Epsilon Drive               Email: wschrier@neolinear.com
Pittsburgh, PA  15238

Re: reiserfsck failure

[Oleg Drokin]

Hello!

On Wed, Jan 15, 2003 at 03:15:13PM -0500, Bill Schrier wrote:
> Unfortunatly, the console was completely hosed up and I couldn't even get any
> display on it to record any messages to stderr.  Sorry - don't think I can help
> there...

Hm. You still have not told us what version of reiserfsck was that.
Also can you please capture metadata snapshot for us
(debugreiserfs -p /dev/yourdevice | bzip2 -9c >metadata.bz2 )
and make it available for us to download?
Thank you.

Bye,
    Oleg

Re: reiserfsck failure

[Bill Schrier]

Oleg, creating that file now.  I will send instructions on where/how to download
once it is ready.

Vitaly, I'm sure that I used the same reiserfsck each time.  We did nothing on the
system to change anything.  It is possible that the core file came from the --check
run.  Over the past week or so, we've run one --check, one --rebuild-tree that
failed, and one --rebuild-tree that succeeded.  The system is now up and running in
a usable state.

Bill

Oleg Drokin wrote:

> Hello!
>
> On Wed, Jan 15, 2003 at 03:15:13PM -0500, Bill Schrier wrote:
> > Unfortunatly, the console was completely hosed up and I couldn't even get any
> > display on it to record any messages to stderr.  Sorry - don't think I can help
> > there...
>
> Hm. You still have not told us what version of reiserfsck was that.
> Also can you please capture metadata snapshot for us
> (debugreiserfs -p /dev/yourdevice | bzip2 -9c >metadata.bz2 )
> and make it available for us to download?
> Thank you.
>
> Bye,
>     Oleg

--
William J. Schrier              Phone: 412.968.5780 x151
Neolinear, Inc.                 Fax:   412.968.5788
583 Epsilon Drive               Email: wschrier@neolinear.com
Pittsburgh, PA  15238

Re: reiserfsck failure

[Vitaly Fertman]

Hi,

On Thursday 16 January 2003 16:19, Bill Schrier wrote:
> Oleg, creating that file now.  I will send instructions on where/how to
> download once it is ready.
>
> Vitaly, I'm sure that I used the same reiserfsck each time.  We did nothing
> on the system to change anything.  It is possible that the core file came
> from the --check run.  Over the past week or so, we've run one --check, one
> --rebuild-tree that failed, and one --rebuild-tree that succeeded.  The
> system is now up and running in a usable state.
>
> Bill

If your system is now recovered then that metadata dump you are making with
debugreiserfs won't be very useful - it can just show the state of files you 
have now, but not before, when fsck segfaults. Please use the uptodate version 
of reiserfsprogs, for now it is 3.6.4. And do not forget to email us with any 
problem you have.

-- 

Thanks,
Vitaly Fertman

Re: reiserfsck failure

[Vitaly Fertman]

On Thursday 16 January 2003 16:48, Vitaly Fertman wrote:
> Hi,
>
> On Thursday 16 January 2003 16:19, Bill Schrier wrote:
> > Oleg, creating that file now.  I will send instructions on where/how to
> > download once it is ready.
> >
> > Vitaly, I'm sure that I used the same reiserfsck each time.  We did
> > nothing on the system to change anything.  It is possible that the core
> > file came from the --check run.  Over the past week or so, we've run one
> > --check, one --rebuild-tree that failed, and one --rebuild-tree that
> > succeeded.  The system is now up and running in a usable state.
> >
> > Bill
>
> If your system is now recovered then that metadata dump you are making with
> debugreiserfs won't be very useful - it can just show the state of files
> you have now, but not before, when fsck segfaults. Please use the uptodate
> version of reiserfsprogs, for now it is 3.6.4. And do not forget to email
> us with any problem you have.

..reiserfs related problem..

-- 

Thanks,
Vitaly Fertman

reiserfsck failure

[Vance_Petree]

Hardware: Microway Alpha EV68AL (Tsunami DP264)
	  2gb memory

Kernel:	  Linux 2.4.18 
	  ReiserFS version 3.6.25
	  Using r5 hash to sort names

Partitions:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2            1008M  613M  343M  64% /
/dev/sda5              31G  6.9G   22G  24% /usr
/dev/sdc1            1011G  1.9G 1009G   0% /mnt/sdc1
/dev/sdb1            1014G  421G  593G  42% /mnt/sdb1

The suspect partition is /dev/sdb1 (I  remounted it just to get the df
output;  it  was  unmounted  when performing  the  reiserfsck).   This
partition  is on  an external  Raidzone raid  5 array  which  shows no
errors.  The motivation for performing  the reiserfsck was a series of
syslog messages  (formatted slightly  to fit in  this email;  many are
similar, but I've included the entire set):

======================================================================
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=0 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341142. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=0 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341142. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216322 0x0 SD] 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=0 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341142. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216323 0x0 SD] 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=0 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341142. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216333 0x0 SD] 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=4 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341145. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216334 0x0 SD] 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong:
		level=1, nr_items=32775, free_space=4 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid
		format found in block 265341145. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216335 0x0 SD] 
Feb 17 13:26:07 gdmsfm00 kernel: is_leaf: nr_item seems wrong: 
		level=1, nr_items=32775, free_space=4 rdkey  
Feb 17 13:26:07 gdmsfm00 kernel: vs-5150: search_by_key: invalid 
		format found in block 265341145. Fsck? 
Feb 17 13:26:07 gdmsfm00 kernel: vs-13070: reiserfs_read_inode2: i/o 
		failure occurred trying to find stat data of 
		[133179756 133216336 0x0 SD] 
======================================================================

Here is the reiserfsck output,  also formatted slightly to fit in this
email:

======================================================================
[root@gdmsfm00 sw]# reiserfsck --fix-fixable -q -y  /dev/sdb1
reiserfsck 3.6.12 (2003 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check consistency of the filesystem on /dev/sdb1
and will fix what can be fixed without --rebuild-tree
Will put log info to 'stdout'
###########
reiserfsck --fix-fixable started at Mon Feb 23 10:41:12 2004
###########
Replaying journal..
0 transactions replayed
Checking internal tree..block 245180252: The number of items (32813) 
 is incorrect, should be (45)
 the problem in the internal node occured (245180252), whole subtree is skipped
block 245177629: The number of items (32825) is incorrect, should be (58)
 the problem in the internal node occured (245177629), whole subtree is skipped
block 245675168: The number of items (32801) is incorrect, should be (33)
 the problem in the internal node occured (245675168), whole subtree is skipped
block 265341142: The number of items (32775) is incorrect, should be (0)
 the problem in the internal node occured (265341142), whole subtree is skipped
finished
Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps
differs. Will be fixed later.
File size limit exceeded (core dumped)
======================================================================

There were no additional messages via syslog or dmesg. I have retained
the  core file  of you  would like  it (or  would like  me to  look up
anything in it).

Please let me know if you require additional information. Thanks!

-- 
======================================================================
Vance W. Petree                vwp@acm.org                804-273-3276