Re: corruption, xfs_repair 3.1.4 segfaults

From: Eric Sandeen <sandeen@sandeen.net>
To: Marc Lehmann <schmorp@schmorp.de>
Cc: xfs@oss.sgi.com
Subject: Re: corruption, xfs_repair 3.1.4 segfaults
Date: Fri, 04 Mar 2011 13:18:17 -0600	[thread overview]
Message-ID: <4D713AF9.4050101@sandeen.net> (raw)
In-Reply-To: <20110304163157.GA2030@schmorp.de>

On 3/4/11 10:31 AM, Marc Lehmann wrote:

> On Fri, Mar 04, 2011 at 09:07:09AM -0600, Eric Sandeen <sandeen@sandeen.net> wrote:
>>> I had a case of filesystem corruption a day ago:
>>
>> If you provide an xfs_metadump image of the filesystem, I'd be
>> happy to look into the cause of the segfault.
> 
> That is the second thing that came to my mind, but this disk contains
> sensitive data, and as long as the anonymise/obfuscate option of xfs_metadump
> is broken (a simple hexdump reveals most of the filenames it's supposed to
> obfuscate), I unfortunately cannot.

Do you have a lot of short names?  It should be obfuscating the others
just fine.  Otherwise, Alex has been working on the obfuscation, maybe
he can give you some pointers.

BTW no need to run hexdump; you can xfs_mdrestore the dump, and loopback
mount it, and do a find to see what filenames are there.

(unless you mean the clear names are seen in hexdump but not on the
mounted, restored fs?  If so that's a new and interesting problem).

> (the xfs_metadump -o bug has been reported in the past btw., if it's fixed
> in git I could give thta another try).

well... "-o" DISABLEs obfuscation.  If you use it and see all filenames,
that is exactly as it should be working ;)  Don't use -o if you want
obfuscation (I know, it seems a little backwards to me too).

>> In my experience xfs_repair does not almost always crash, if you
>> encounter this, please do send mail/file bugs/provide images.
> 
> Well, I did (as well as other people did), in the past, and the bugs
> that were reported wree fixed (For example, I stumbled over the problem
> of the xfs_repair livelock with threads, I stumbled over the problem of
> it not being able to repair corruption a number of times despite saying
> everything is ok and so on).
> 
> So "crash" was indeed badly worded - "does not fix things or does not run to
> completion" is more correct.

well, keep reporting them, and with metadumps when possible.

> The fact remains that of reiserfs, ext2/3/4 and jfs, xfs has by far the
> lowest quality fsck, at least for me - each time I have some problem with an
> xfs filesystem, xfs_repair fails to repair it.

I think that's unique to you ;)  but it also depends on your definition
of "quality."

Of course, properly completing repair is a fair definition!  Really, these
things need to be reported, triaged, and fixed.  If the confusion over
metadump was the proper usage of "-o" then perhaps you will be able
to submit some of your unfixable corruptions.

-Eric

> It fortunately doesn't happen often, and is not necessarily a problem with
> xfs itself, but I am using reiserfs and ext2/3/4 and xfs all for a very
> long time, and of these, it's quite obvious that xfs_repair is much worse
> then the fsck tools of the others.

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