From: Dave Chinner <david@fromorbit.com>
To: Viet Nguyen <vietnguyen@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_repair segfault
Date: Wed, 9 Oct 2013 07:23:42 +1100 [thread overview]
Message-ID: <20131008202342.GA4446@dastard> (raw)
In-Reply-To: <CAGa4099NNUJV4_JbU0izLf0k3bcj3afHPTXt=HO2263_TESbNA@mail.gmail.com>
On Mon, Oct 07, 2013 at 01:09:09PM -0700, Viet Nguyen wrote:
> Thanks. That seemed to fix that bug.
>
> Now I'm getting a lot of this:
> xfs_da_do_buf(2): XFS_CORRUPTION_ERROR
Right, that's blocks that are being detected as corrupt when they
are read. You can ignore that for now.
> fatal error -- can't read block 8388608 for directory inode 8628218
That's a corrupted block list of some kind - it should junk the
inode.
> Then xfs_repair exits.
I'm not sure why that happens. Is it exiting cleanly or crashing?
Can you take a metadump of the filesystem and provide it for someone
to debug the problems it causes repair?
> What I've been doing is what I saw in the FAQ where I would use xfs_db and
> write core.mode 0 for these inodes. But there are just so many of them. And
> is that even the right thing to do?
That marks the inode as "free" which effectively junks it and then
xfs_repair will free all it's extents next time it is run. Basically
you are removing the files from the filesystem and making them
unrecoverable.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-10-08 20:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 19:57 xfs_repair segfault Viet Nguyen
2013-10-01 20:19 ` Dave Chinner
2013-10-01 21:12 ` Viet Nguyen
2013-10-02 10:42 ` Dave Chinner
2013-10-04 17:51 ` Viet Nguyen
2013-10-04 21:43 ` Dave Chinner
2013-10-07 20:09 ` Viet Nguyen
2013-10-08 20:23 ` Dave Chinner [this message]
2013-10-09 18:59 ` Viet Nguyen
2013-10-09 20:15 ` Dave Chinner
2013-10-10 21:13 ` Viet Nguyen
-- strict thread matches above, loose matches on Subject: below --
2015-03-09 15:50 Rui Gomes
2015-03-09 15:55 ` Carsten Aulbert
2015-03-09 16:11 ` Rui Gomes
2015-03-09 16:14 ` Eric Sandeen
2015-03-09 16:24 ` Rui Gomes
2015-03-09 17:34 ` Eric Sandeen
2015-03-09 17:50 ` Rui Gomes
2015-03-09 18:18 ` Eric Sandeen
2015-03-09 18:24 ` Rui Gomes
2015-03-09 20:13 ` Eric Sandeen
2007-04-03 19:11 James W. Abendschan
2007-04-04 0:45 ` Barry Naujok
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=20131008202342.GA4446@dastard \
--to=david@fromorbit.com \
--cc=vietnguyen@gmail.com \
--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