xfs
[Top] [All Lists]

Re: Disconnected inodes after test xfs/261

To: Jan Kara <jack@xxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Disconnected inodes after test xfs/261
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 18 Dec 2014 15:27:07 -0600
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141218105614.GE13705@xxxxxxxxxxxxx>
References: <20141217193535.GA8231@xxxxxxxxxxxxx> <20141217210226.GY24183@dastard> <20141218103642.GB13705@xxxxxxxxxxxxx> <20141218105614.GE13705@xxxxxxxxxxxxx>
On 12/18/14 4:56 AM, Jan Kara wrote:
> On Thu 18-12-14 11:36:42, Jan Kara wrote:
>> On Thu 18-12-14 08:02:26, 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.
>>   No, the problem is still there after mounting and unmounting the
>> filesystem.
>>
>> Given what Michael wrote: I'm running xfs_repair version 3.2.1, filesystem
>> is V4.
>   Oh, and what might be related: Test xfs/071 passes but xfs_repair
> complains like:
> *** xfs_repair -n output ***
> 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
> inode 131 - extent offset too large - start 14, count 1, offset 
> 2251799813685247
> correcting nextents for inode 131
> bad data fork in inode 131
> would have cleared inode 131

That's addressed by either 
http://oss.sgi.com/archives/xfs/2014-09/msg00524.html
or
http://oss.sgi.com/archives/xfs/2014-12/msg00106.html

FWIW...

-Eric

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