[Top] [All Lists]

Re: xfs_repair segfault

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_repair segfault
From: Viet Nguyen <vietnguyen@xxxxxxxxx>
Date: Thu, 10 Oct 2013 14:13:43 -0700
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d0HZTJiOV63oVTfidYu32AM/qmTVgOhVJrKlLKnkeaU=; b=HvZ/NqfXfhl50LYmETbO5a/zr2Ro9kznXdYkziRENkUXt0kJnWM2HLC+Vg+VC0sKhh a02XdLMRHD/n0McvDxC7p9m3xuB6khjemTL2b5RJvx6qD9Iy6jCjKNzN+eYhiioR2AFs PQO5D4bLz9S4dfgOzYZj7U5r+6ZwMWIZZA9xx6rD6gbj35G82tsWJmaPdnaS48P8VHj4 zaucOKFxP1NCFcfpzaHYtm05ovYXyjgFD+rNr6EZo1vAVgCJTmd2IkxTGsUyU5F3Mnsw JP9VxyTEjaez5zsvxyrIj3XJwbI5ry3qjtwEPl5edF6HOJr6EB/Lj0JUWtBlBppx8mq1 CfyQ==
In-reply-to: <20131008202342.GA4446@dastard>
References: <CAGa4098ZKd2KQfWMgNXYgLr9LJF8r-MpFgQAn3G-W+ovDGHTAw@xxxxxxxxxxxxxx> <20131001201909.GR12541@dastard> <CAGa409_tDjbsdnf+wDiM7666FeQSjmMfOVdqG-SxOD_WUZMiZQ@xxxxxxxxxxxxxx> <20131002104253.GT12541@dastard> <CAGa409_wO74zGP1d85RGZ7WbfBPr7s_tKaW3u9k8=9Ps-D5FjQ@xxxxxxxxxxxxxx> <20131004214353.GK4446@dastard> <CAGa4099NNUJV4_JbU0izLf0k3bcj3afHPTXt=HO2263_TESbNA@xxxxxxxxxxxxxx> <20131008202342.GA4446@dastard>
Luckily the files that I want to recover have metadata in them that will help me rebuild their names. So I'm okay with blowing away the directory inodes. I guess I wish there was a flag that I can pass to say that xfs_repair can junk those for me instead of having to do it manually each time.

So, the compressed metadump file is 2.4G. Any suggestions on where I should put it, and who I send it to?

On Tue, Oct 8, 2013 at 1:23 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
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

> 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


Dave Chinner

xfs mailing list

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