[Top] [All Lists]

Re: xfs_repair segfaults

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_repair segfaults
From: Ole Tange <tange@xxxxxxxxxx>
Date: Fri, 8 Mar 2013 11:21:00 +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=Ax7MJHNdD+q3BVegMKTRIUOPbdsigQIDboQU83Fw3NI=; b=mLdbL+f7Bj3Fvho8ZB0ez2/pKjuz/Z6TDrEwtJcK0ywzW/r4Op/4y84u40K/Uyazzi 0goiHub1epd78MgaAfuaRwzYuNRQY+RtgDEuTv+sl6BYqZRoJov5rq2xwM6Xx9PPdVRt 4ySvk9CX5Nt1ElHpepr9+KBIpg8nrRVyXTbE8nIBhSqm+/d9KKILYtN1SIVtVbkGGJ0S 3SKRHr0xhY3WX5qLBGyLbmj9ZjZTLj+00Gy3S8boJ5sUmyHstfp4TOkSaQ7Rr2BXy0Rl kEb12f5yLQ7hHaXyZsAFMt8ny7oNjD5T2MeZe6jsDFfq+3PjnMCKj5k+H8fGhbIGcdm/ ZlgA==
In-reply-to: <5134BBA4.3060305@xxxxxxxxxxx>
References: <CANU9nTnvJS50vdQv2K0gKHZPvzzH5EY1qpizJNsqUobrr2juDA@xxxxxxxxxxxxxx> <512FA67D.2090708@xxxxxxxxxxx> <CANU9nTm3vR3Z5JwRwou4vnNejstAkAsnBb2ivwx-KhnHHbWpoQ@xxxxxxxxxxxxxx> <5130DB54.9030503@xxxxxxxxxxx> <CANU9nTkekrw2mdptFdK2RVUFXD=evt0sTZhB9VL+PKY8DTj11A@xxxxxxxxxxxxxx> <5134BBA4.3060305@xxxxxxxxxxx>
Sender: ole.tange.work@xxxxxxxxx
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

I have now done a 'xfs_repair' using the code in GIT. It failed, and I
then did 'xfs_repair -L' which succeeded.

Am I correct that I should now be able to mount the sparse disk-image
file and see all the filenames? In that case I am quite worried. I get
filenames like:

X[Df?Wm^[?f 4|

My guess is some superblock is corrupt and that it should instead try
a backup superblock. It might be useful if xfs_repair could do this
automatically based on the rule of thumb that more than 90% of
filenames/dirnames match:

[- _.,=A-Za-z0-9':]* [([{]* [- _.,=A-Za-z0-9':]* []})]* [- _.,=A-Za-z0-9':]*

If it finds a superblock resulting in more then 10% not matching the
above it should probably ignore that superblock (unless the file names
are using non-latin characters - such as Japanese).


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