All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: Hanne Munkholm <hanne@binf.ku.dk>
Cc: xfs@oss.sgi.com
Subject: Re: "Corrupt dinode 6242615, (btree extents).  This is a bug."<o
Date: Mon, 8 Aug 2011 15:12:35 +0200	[thread overview]
Message-ID: <201108081512.36783@zmi.at> (raw)
In-Reply-To: <alpine.OSX.1.00.1108081422500.240@pegasus.binf.ku.dk>


[-- Attachment #1.1: Type: Text/Plain, Size: 1575 bytes --]

On Montag, 8. August 2011 Hanne Munkholm wrote:
> On Mon, 8 Aug 2011, Michael Monnerie wrote:
> > Yes, mount -L/umount once to replay the log, when you are sure the
> > block device works correctly again.
> 
> Thank you very much for your reply.
> 
> I don't see an -L option to the mount command meaning "replay
> log", I think if I was able to mount it, it would replay the log
> by itself? However, I cannot mount it.

Sorry, mixing up with xfs_repair -L. If mount doesn't work, then try to 
xfs_repair -L.

> Trying with a newer kernel is possible but some trouble, is it
> likely to help?

Could be. Dave Chinner knows more. I'd say if a newer kernel is 
problematic, try xfs_repair -L first, and keep the output for review. As 
you have a backup anyway, you're on the safe side. I've needed 
xfs_repair often and never had a problem because of it. YMMV though.
 
> If I run an xfs_repair, will it get me anywhere even if it
> segfaults at the same point?

Yes, sometimes running it several times solves all problems.
 
> Do you recommend that I run an xfs_repair with or without -L, or
> should I definetly try a new kernel first?

If you can quickly download a "live" CD with an actual kernel, do that 
and try that. If that is problematic, e.g. you don't have access to the 
server, just run xfs_repair -L.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-08-08 13:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 10:05 "Corrupt dinode 6242615, (btree extents). This is a bug." Hanne Munkholm
2011-08-08 11:58 ` Michael Monnerie
2011-08-08 12:53   ` "Corrupt dinode 6242615, (btree extents). This is a bug."<o Hanne Munkholm
2011-08-08 13:12     ` Michael Monnerie [this message]
2011-08-08 23:58 ` "Corrupt dinode 6242615, (btree extents). This is a bug." Dave Chinner
2011-08-09  8:47   ` Hanne Munkholm

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=201108081512.36783@zmi.at \
    --to=michael.monnerie@is.it-management.at \
    --cc=hanne@binf.ku.dk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.