On Thu 18-12-14 16:21:58, Michael L. Semon wrote: > 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. > > OK, I played with this a bit, though in all but one case, my XFS stack > is new. A bisect will be done to find when this started. kernel > 3.10.63 here at work is OK, where new xfsprogs is installed. > > In trying out new kernels, I hit the "kernel too old" wall on boot. > Therefore, a new system was brewed from slackware-current, and xfstests > was installed on top of that. This result is from the "huge-smp" > vendor kernel, as it came from the original binary packages: > > root@kyhorse:/var/lib/xfstests# uname -a > Linux kyhorse 3.14.24-smp #2 SMP Fri Nov 14 18:34:21 CST 2014 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz GenuineIntel GNU/Linux > > root@kyhorse:/var/lib/xfstests# ./check xfs/261 > FSTYP -- xfs (non-debug) > PLATFORM -- Linux/i686 kyhorse 3.14.24-smp > MKFS_OPTIONS -- -f -bsize=4096 /dev/sda7 > MOUNT_OPTIONS -- /dev/sda7 /mnt/scratch > > xfs/261 2s ... 3s > _check_xfs_filesystem: filesystem on /dev/sda7 is inconsistent (c) (see /var/lib/xfstests/results//xfs/261.full) > _check_xfs_filesystem: filesystem on /dev/sda7 is inconsistent (r) (see /var/lib/xfstests/results//xfs/261.full) > Ran: xfs/261 > Passed all 1 tests > > root@kyhorse:/var/lib/xfstests# xfs_repair $SCRQ ATCH_DEV > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and 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 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > - traversal finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 132, moving to lost+found > disconnected inode 133, moving to lost+found > Phase 7 - verify and correct link counts... > Note - quota info will be regenerated on next quota mount. > done > > A mount/umount sequence did not change matters. xfsprogs appears to > be version 3.1.11, glancing from the tarball names in the a/ directory > here: > > ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/ > > The new setup was just made bootable before I came in to work, and the > bisect will start tonight and will hopefully be posted by Monday night. I have found the culprit of the bug so no bisection is needed. See my other email in this thread... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
