xfs
[Top] [All Lists]

Re: xfs filesystem corruption with kernel 2.6.37

To: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Subject: Re: xfs filesystem corruption with kernel 2.6.37
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 4 Nov 2012 09:25:18 +1100
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
In-reply-to: <37CBCD87-5B71-4B9C-8FAE-5BBF85804983@xxxxxxxxx>
References: <CAC=U0a2T_J9Y6WzvWyFfbBSDy__Pr7f4gfQBie2o0VhAm2jCaQ@xxxxxxxxxxxxxx> <20121025224713.GF29378@dastard> <34630253.post@xxxxxxxxxxxxxxx> <20121102012728.GT29378@dastard> <34633803.post@xxxxxxxxxxxxxxx> <20121102225509.GZ29378@dastard> <37CBCD87-5B71-4B9C-8FAE-5BBF85804983@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Nov 02, 2012 at 09:57:27PM -0400, Kamal Dasu wrote:
> Dave,
> 
> 
> > 
> > 0x780dbd80007f248
> > 
> > Once again it's corruption in the upper 32 bits of the 64 bit number.
> > Those bits should be zero. Perhaps looking at all the trace events
> > from recovery might give you a closer approximation of where the bad
> > extent records is found....
> 
> I have been trying to use the xfs_db xfs_logprint, how ever
> xfs_logprint bails out when it finds an error.

$ man xfs_logprint
....
        -c     Attempt to continue when an error is detected.

> How do I look at
> trace events ?.

Documentation/trace/events.txt

Or better yet, use trace-cmd as suggested in the FAQ:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>