Re: Disconnected inodes after test xfs/261

[Jan Kara <jack@suse.cz>]

[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]

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.

When I look via xfs_db at the inode I can see nlink is 1 which looks
strange. So maybe the problem is somewhere else than I thought:
xfs_db> inode 132
xfs_db> p
core.magic = 0x494e
core.mode = 0100000
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid_lo = 0
core.projid_hi = 0
core.uid = 0
core.gid = 0
core.flushiter = 1
core.atime.sec = Thu Dec 18 11:08:55 2014
core.atime.nsec = 510013169
core.mtime.sec = Thu Dec 18 11:08:55 2014
core.mtime.nsec = 510013169
core.ctime.sec = Thu Dec 18 11:08:55 2014
core.ctime.nsec = 510013169
core.size = 0
core.nblocks = 1
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 0
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,13,1,0]

I have taken xfs_metadump just after test xfs/261 completed and xfs_repair
reported error. It is attached.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[-- Attachment #2: xfs-inode.img.xz --]
[-- Type: application/x-xz, Size: 21672 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs