Re: xfsdump SGI_FS_BULKSTAT errno = 22, how could this IRIX bug get into Ubuntu 10.04 Lucid between kernels 2.6.32-27 and 2.6.32-26?

From: Dave Chinner <david@fromorbit.com>
To: Michael Lueck <mlueck@lueckdatasystems.com>
Cc: linux-xfs@oss.sgi.com, Dann Frazier <dannf@debian.org>
Subject: Re: xfsdump SGI_FS_BULKSTAT errno = 22, how could this IRIX bug get into Ubuntu 10.04 Lucid between kernels 2.6.32-27 and 2.6.32-26?
Date: Wed, 9 Feb 2011 09:47:07 +1100	[thread overview]
Message-ID: <20110208224707.GF2559@dastard> (raw)
In-Reply-To: <4D51A695.6060700@lueckdatasystems.com>

On Tue, Feb 08, 2011 at 03:24:53PM -0500, Michael Lueck wrote:
> Michael Lueck wrote:
> >I will IPL the server to the latest kernel and run the tests immediately.
> 
> Here they are attached...
>
> # sudo xfs_db -c "inode 80508397" -c p /dev/sda9 2>&1 | tee xfs_db-inode_80508397.log
> core.magic = 0x494e
> core.mode = 040777
> core.version = 2
> core.format = 2 (extents)
> core.nlinkv2 = 2
> core.onlink = 0
> core.projid = 0
> core.uid = 1000
> core.gid = 1000
> core.flushiter = 10
> core.atime.sec = Sun Feb  6 16:59:44 2011
> core.atime.nsec = 088915516
> core.mtime.sec = Tue Jan 11 13:50:51 2011
> core.mtime.nsec = 950662167
> core.ctime.sec = Tue Jan 11 13:50:51 2011
> core.ctime.nsec = 950662167
> core.size = 4096
> 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 = 3978985788
> next_unlinked = null
> u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,5052169,1,0]

Nothing wrong with that inode....

> # sudo xfs_repair -n /dev/sda9 2>&1 | tee xfs_repair-srv.log
> 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 ...
> Phase 7 - verify link counts...
> No modify flag set, skipping filesystem flush and exiting.

And no errors detected in the filesystem. Can you run the xfsdump
again to confirm that it fails on the same inode? If it doesņ then
it definitely seems like an alignment problem in the untrusted inode
lookup patches....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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