xfs
[Top] [All Lists]

Re: corrupt xfs filesystem -- xfs_repair dumps core

To: Willi.Langenberger@xxxxxxxxxxxxx
Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core
From: Nathan Scott <nathans@xxxxxxx>
Date: Wed, 24 Apr 2002 08:27:48 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <15557.36194.760672.792045@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, Apr 23, 2002 at 06:35:46PM +0200
References: <15557.36194.760672.792045@slime.wu-wien.ac.at>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Apr 23, 2002 at 06:35:46PM +0200, Willi Langenberger wrote:
> Hi!

Hi there,

> The problems began with disappearing directories. We tried a
> xfs_repair (1.2.8), but without luck. Unfortunatly, my colleague
> hasn't saved the output from that run.
> 
> Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump:
> 
>   # /sbin/xfs_repair /dev/sdb
>   Phase 1 - find and verify superblock...
>   Phase 2 - using internal log
>           - zero log...
>   xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion 
> `start_blk != 0 || *last_blk != start_blk' failed.
>   Aborted (core dumped)
> 
> Should this happen? The Kernel Upgrade from 2.4.3-SGI_XFS_1.0.1 to
> 2.4.9-31SGI_XFS_1.1 made no difference.

Ah, I see the problem.  You have an unclean log and corruption in
the log which is causing the code in xfs_repair to get confused when
searching for the log head/tail.

First try mount, then unmount, and then run xfs_repair.  The initial
mount/unmount will cause the log to be replayed, if it can be.

Failing that, try "xfs_repair -L /dev/sdb" which skips the check for
an empty log, zeroes it, then goes ahead with repairing.

Failing that (!) we can get libxlog built non-debug so this assertion
doesn't get tripped, and see how we go from there.

cheers.

-- 
Nathan


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