Thread (6 messages) 6 messages, 3 authors, 2011-08-09

Re: "Corrupt dinode 6242615, (btree extents). This is a bug."<o

From: Michael Monnerie <hidden>
Date: 2011-08-08 13:12:41

On Montag, 8. August 2011 Hanne Munkholm wrote:
On Mon, 8 Aug 2011, Michael Monnerie wrote:
quoted
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help