public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Lehmann <schmorp@schmorp.de>
To: xfs@oss.sgi.com
Subject: Re: corruption, xfs_repair 3.1.4 segfaults
Date: Fri, 4 Mar 2011 17:31:57 +0100	[thread overview]
Message-ID: <20110304163157.GA2030@schmorp.de> (raw)
In-Reply-To: <4D71001D.2040506@sandeen.net> <20110304121407.065d9f17@harpe.intellique.com>

On Fri, Mar 04, 2011 at 12:14:07PM +0100, Emmanuel Florac <eflorac@intellique.com> wrote:
> > I think that, no matter what the loop device would do, xfs_repair is
> > - it simply shouldn't crash, no matter how corrupted the filesystem
> 
> That's true. After you've copied everything, you could try using

It seems only a single directory was not readable (which is a backup), so all
data could be recovered. I am currently checking md5sums, but it seems that's
indeed it.

Which might make sense, as xfs_repair crashes after reading a XD2D
block. The backtrace I get when using rsync to copy over files also
supports this:

   http://ue.tst.eu/2bda1b4532cc66248763f723988093ce.txt

> Lenny's xfs_repair (v 2.9.x IIRC). Just in case, it may do better.

I will give that a shot, thanks for the hint, I will report back on this.

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.

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

> 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.

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.

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.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

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

  reply	other threads:[~2011-03-04 16:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02 17:58 corruption, xfs_repair 3.1.4 segfaults Marc Lehmann
2011-03-02 21:43 ` Emmanuel Florac
2011-03-04  7:11   ` Marc Lehmann
2011-03-04  7:51     ` Emmanuel Florac
2011-03-04 10:29       ` Marc Lehmann
2011-03-04 11:14         ` Emmanuel Florac
2011-03-04 16:31           ` Marc Lehmann [this message]
2011-03-04 19:18             ` Eric Sandeen
2011-03-04 17:30           ` corruption, xfs_repair 3.1.4 segfaults, xfs_repair 2.9.8 works Marc Lehmann
2011-03-04 18:17             ` Emmanuel Florac
2011-03-04 15:07 ` corruption, xfs_repair 3.1.4 segfaults Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2011-03-02 17:57 Marc Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110304163157.GA2030@schmorp.de \
    --to=schmorp@schmorp.de \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox