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
- 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
entry "071" in shortform directory 128 references free inode 131
would have junked entry "071" in directory inode 128
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
- agno = 1
- agno = 2
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
entry "071" in shortform directory inode 128 points to free inode 131
would junk entry
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
