public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Shimmin <tes@sgi.com>
To: xfs@oss.sgi.com
Subject: Re: 2.6.24-rc3 oopses while mounting fs
Date: Tue, 04 Dec 2007 11:11:06 +1100	[thread overview]
Message-ID: <47549B1A.4070508@sgi.com> (raw)
In-Reply-To: <20071203220200.GC13667@luba>

Hi Peter,

FYI

Just a couple of things in case you weren't aware.
Often it is simplest to save the log using the -C option to a file.
        -C filename
               Copy the log from the filesystem to the file filename.
               The log itself is not printed.
The log can then be analysed in various ways later.

Running logprint in operation mode (the default mode without options)
(non-transaction mode without -t)
is really pretty useless without the -s option.
If you use the -s option then one needs to know where to seek to
(you can use -t to find the head/tail or -d to see where log records start).
The problem here is that if you do logprint
like this (no options) then it will start at offset zero and will invariably have
trouble decoding if the log has wrapped around (the general case) as
you'll start in the middle of a record.
So the -t option is often a more interesting starting point as it
will operate more like the file system recovery does, finding the head and tail,
and processing from the tail to the head of the log.

If you want to save the filesystem away for possible metadata debugging later,
then xfs_metadump is your friend.

Cheers,
Tim.

KELEMEN Peter wrote:
> * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]:
> 
> Lachlan,
> 
>> Okay, sounds like it might be a corrupt log.
> 
> Yep.
> 
>> Can you run xfs_logprint on the device or saved log?
> 
> Sure.
> 
> http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2
> It aborted though, with the following message:
> 
> 	xfs_logprint: unknown log operation type (343b)
> 	Bad data in log
> 
>> Also give xfs_logprint -t -i a go.
> 
> http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2
> 
>> You've saved the log into a file?  You can get the filesystem
>> mounted again by deleting the log with xfs_repair -L <dev>.
>> You'll probably need to run xfs_repair over the filesystem to be
>> safe.
> 
> I conserved this filesystem away for further analysis, I'm not
> sure how helpful it can be.
> 
> Thanks,
> Peter
> 

  reply	other threads:[~2007-12-04  0:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 13:45 2.6.24-rc3 oopses while mounting fs KELEMEN Peter
2007-11-28 23:56 ` Lachlan McIlroy
2007-11-30 22:31   ` KELEMEN Peter
2007-12-03  3:24     ` Lachlan McIlroy
2007-12-03 22:02       ` KELEMEN Peter
2007-12-04  0:11         ` Timothy Shimmin [this message]
2007-12-04  7:08           ` Lachlan McIlroy
2007-12-04  9:57             ` KELEMEN Peter
2007-12-05  5:47             ` Lachlan McIlroy
2007-12-05  6:38               ` Timothy Shimmin
2007-12-05  7:04                 ` Lachlan McIlroy
2007-12-04  9:42           ` KELEMEN Peter

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=47549B1A.4070508@sgi.com \
    --to=tes@sgi.com \
    --cc=xfs@oss.sgi.com \
    /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