From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>
Cc: xfs@oss.sgi.com
Subject: Re: Disconnected inodes after test xfs/261
Date: Wed, 17 Dec 2014 19:46:17 -0500 [thread overview]
Message-ID: <549223D9.5020202@gmail.com> (raw)
In-Reply-To: <20141217210226.GY24183@dastard>
On 12/17/14 16:02, Dave Chinner wrote:
> On Wed, Dec 17, 2014 at 08:35:35PM +0100, Jan Kara wrote:
>> Hello,
>>
>> in my test KVM with today's Linus' kernel I'm getting xfs_repair
>> complaint about disconnected inodes after the test xfs/261 finishes
>> (with success). xfs_repair output is like:
>> xfs_repair -n /dev/vdb2
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>> - scan filesystem freespace and inode maps...
>> - found root inode chunk
>> Phase 3 - for each AG...
>> - scan (but don't clear) agi unlinked lists...
>> - process known inodes and perform inode discovery...
>> - agno = 0
>> - agno = 1
>> - agno = 2
>> - agno = 3
>> - process newly discovered inodes...
>> Phase 4 - check for duplicate blocks...
>> - setting up duplicate extent list...
>> - check for inodes claiming duplicate blocks...
>> - agno = 0
>> - agno = 1
>> - agno = 2
>> - agno = 3
>> No modify flag set, skipping phase 5
>> Phase 6 - check inode connectivity...
>> - traversing filesystem ...
>> - traversal finished ...
>> - moving disconnected inodes to lost+found ...
>> disconnected inode 132, would move to lost+found
>> disconnected inode 133, would move to lost+found
>> Phase 7 - verify link counts...
>> No modify flag set, skipping filesystem flush and exiting.
>> ---
>> Given how trivial test xfs/261 is, it seems like created private mtab files
>> that also get unlinked don't get added to AGI unlinked list before umount.
>> I didn't have a detailed look whether that's possible or not and probably
>> won't get to it before Christmas. So I'm sending this just in case someone
>> more knowledgeable has ideas earlier...
>
> I don't see that here. If you mount/unmount the filesystem, does the
> warning go away? i.e. xfs_repair -n ignores the contents of
> the log, so if the unlinked list transactions are in the log then
> log recovery will make everything good again.
>
> That said, if unmount is not leaving the log clean, then we've still
> got an issue we need to get to the bottom of.
>
> Cheers,
>
> Dave.
I've seen this but seemingly only on v4-superblock XFS and only with Dave's
xfsprogs RFC libxfs patches applied. [Nice patchset, BTW.] Will `git pull`
everything again, then take it home to the x86 dungeon and test it again.
Good luck!
Michael
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-12-18 0:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 19:35 Disconnected inodes after test xfs/261 Jan Kara
2014-12-17 21:02 ` Dave Chinner
2014-12-18 0:46 ` Michael L. Semon [this message]
2014-12-18 10:36 ` Jan Kara
2014-12-18 10:56 ` Jan Kara
2014-12-18 21:27 ` Eric Sandeen
2014-12-18 13:55 ` Jan Kara
2014-12-19 2:03 ` Dave Chinner
2014-12-21 23:41 ` Michael L. Semon
2014-12-18 21:21 ` Michael L. Semon
2014-12-18 21:54 ` Jan Kara
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=549223D9.5020202@gmail.com \
--to=mlsemon35@gmail.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--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