From: Eric Sandeen <sandeen@redhat.com>
To: Carlos Maiolino <cem@kernel.org>, iamdooser <iamdooser@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: xfs_repair hangs at "process newly discovered inodes..."
Date: Mon, 21 Nov 2022 10:24:02 -0600 [thread overview]
Message-ID: <084cd831-d64b-6add-f8c7-d82c076da818@redhat.com> (raw)
In-Reply-To: <20221121161400.tecpfwaawiy4kt3y@andromeda>
On 11/21/22 10:14 AM, Carlos Maiolino wrote:
> Hi.
>
>
> On Sat, Nov 19, 2022 at 12:24:18PM -0500, iamdooser wrote:
>> Thank you for responding.
>>
>> Yes that found errors, although I'm not accustomed to interpreting the
>> output.
>>
>> xfs_repair version 5.18.0
>>
>> The output of xfs_repair -nv was quite large, as was the
>> xfs_metadump...not sure that's indicative of something, but I've
>> uploaded them here:
>> https://drive.google.com/drive/folders/1OyQOZNsTS1w1Utx1ZfQEH-bS_Cyj8-F2?usp=sharing
>>
>>
>> There doesn't seem to be much activity once it hangs at "process newly
>> discovered inodes..." so it doesn't seem like just a slow repair.
>> Desipte there being no sign of activity, I've let it run for 24+ hours
>> and saw no changes..
>>
>
> Before anything else, could you please try to run the latest xfsprogs from:
>
> https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/log/?h=master
>
> A quick test in my laptop using the metadump you provided, finished the repair
> in about 5 mintues:
>
> Maximum metadata LSN (2138201505:-135558109) is ahead of log (96:0).
> Format log to cycle 2138201508.
>
> XFS_REPAIR Summary Mon Nov 21 17:04:44 2022
>
> Phase Start End Duration
> Phase 1: 11/21 16:59:36 11/21 16:59:36
> Phase 2: 11/21 16:59:36 11/21 16:59:37 1 second
> Phase 3: 11/21 16:59:37 11/21 17:03:47 4 minutes, 10 seconds
> Phase 4: 11/21 17:03:47 11/21 17:04:06 19 seconds
> Phase 5: 11/21 17:04:06 11/21 17:04:07 1 second
> Phase 6: 11/21 17:04:07 11/21 17:04:38 31 seconds
> Phase 7: 11/21 17:04:38 11/21 17:04:38
>
> Total run time: 5 minutes, 2 seconds
> done
>
> Also, feel free to compress any file you need to share with us :)
Yup. All those files should compress quite well.
So, the "-nv" output shows many, many errors. While xfs_repair should eventually
make the filesystem metadata consistent again, that's not the same thing as data
recovery.
What happened to this filesystem and/or its storage that prompted the need for
repair?
-Eric
next prev parent reply other threads:[~2022-11-21 16:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 18:40 xfs_repair hangs at "process newly discovered inodes..." iamdooser
2022-11-17 18:48 ` Eric Sandeen
2022-11-19 17:24 ` iamdooser
2022-11-21 16:14 ` Carlos Maiolino
2022-11-21 16:24 ` Eric Sandeen [this message]
2022-11-21 20:48 ` Dave Chinner
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=084cd831-d64b-6add-f8c7-d82c076da818@redhat.com \
--to=sandeen@redhat.com \
--cc=cem@kernel.org \
--cc=iamdooser@gmail.com \
--cc=linux-xfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.