xfs
[Top] [All Lists]

Re: xfs_repair segfaults

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_repair segfaults
From: Ole Tange <tange@xxxxxxxxxx>
Date: Tue, 12 Mar 2013 12:37:46 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ckxfuHmxhU7MJY3vhrXzNAHaNkSEbb8cpnB6mQ5joIQ=; b=CqHrsAyOg8dCT4NyZh7Q80sl63rH2QYaqmd+nLLPCX9pHgztTCInTtsuE7f0VhnIid mATJJrFZpRjPO3aVX1k6Je5HHTcNgHFmKM6GUpaDlfBXMhEdUEc4g4B9stRjMEJidX/o nmaxl1NIRnHytJ+IVRYz001RTQM+roTsj4cni5gcGJe9CsH/bMTnZo/MkIk7I4j+ror/ qpT/a8hdcPPeC/hIMNx77IZR2mlI6/YXpOmB6uTUU/+gBBVY3nFe6A4OM99cqdcQbssz Vv0wBQOfFJP6V3aJUeLWd9zGY2P2OmckRIf/UqsQtVBMaxYcsJf65B1IF7Ih0bI7+H/L a9IQ==
In-reply-to: <CANU9nTntXh5spRYc80OhsBqgLnZcJGA2qBeVVQaywthD1RMu4w@xxxxxxxxxxxxxx>
References: <CANU9nTnvJS50vdQv2K0gKHZPvzzH5EY1qpizJNsqUobrr2juDA@xxxxxxxxxxxxxx> <512FA67D.2090708@xxxxxxxxxxx> <CANU9nTm3vR3Z5JwRwou4vnNejstAkAsnBb2ivwx-KhnHHbWpoQ@xxxxxxxxxxxxxx> <5130DB54.9030503@xxxxxxxxxxx> <CANU9nTkekrw2mdptFdK2RVUFXD=evt0sTZhB9VL+PKY8DTj11A@xxxxxxxxxxxxxx> <5134BBA4.3060305@xxxxxxxxxxx> <CANU9nTntXh5spRYc80OhsBqgLnZcJGA2qBeVVQaywthD1RMu4w@xxxxxxxxxxxxxx>
Sender: ole.tange.work@xxxxxxxxx
(Forgot CC-to list)

On Fri, Mar 8, 2013 at 11:21 AM, Ole Tange <tange@xxxxxxxxxx> wrote:
> On Mon, Mar 4, 2013 at 4:20 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>
>> 2) so you could run a "real" non-"n" xfs_repair on a metadata image as a 
>> more realistic dry run

So I made a new metadata image using xfs_metadump.sh from git:

    ./xfs_metadump.sh -o /dev/md123p1 franklin.xfs.metadump
    pbzip2 franklin.xfs.metadump

Then I restored it:

    pbzip2 -dc < franklin.xfs.noobfuscate.metadump.bz2 |
      time ~/work/xfsprogs/mdrestore/xfs_mdrestore - franklin.img

Then I ran git version of xfs_repair (first with -n, then no option,
then with -L):

$ ~/work/xfsprogs/repair/xfs_repair -n franklin.img
# Load of output. Completes OK.

$ ~/work/xfsprogs/repair/xfs_repair  franklin.img
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

$ ~/work/xfsprogs/repair/xfs_repair -L franklin.img
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
xfs_repair: scan.c:1080: scan_freelist: Assertion `0' failed.
Aborted (core dumped)

Then I restored the metadata:

    pbzip2 -dc < franklin.xfs.noobfuscate.metadump.bz2 |
      time ~/work/xfsprogs/mdrestore/xfs_mdrestore - franklin.img

Then I ran xfs_repair version 3.1.7. This gave a lot of output but
completed without core dumping.

The resulting filesystem was mountable and contained at least some of
the filenames I expected.

I believe either there is a new bug in the git version, or it simply
discovers a bug that 3.1.7 does not.

metadata, xfs_repair binary, core:
http://dna.ku.dk/~tange/xfs/


/Ole

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