Re: [PATCH 0/6 v2] xfs: fix the bulkstat mess

[Dave Chinner <david@fromorbit.com>]

On Wed, Nov 05, 2014 at 08:17:06AM -0500, Brian Foster wrote:
> On Wed, Nov 05, 2014 at 05:32:26PM +1100, Dave Chinner wrote:
> > OK, this looks like a problem with handling the last record in the
> > AGI btree:
> > 
> > $ for i in `cat s.diff | grep "^+/" | sed -e 's/^+//'` ; do ls -i $i; done |sort -n
> > 163209114099 /mnt/scratch/2/dbc/5459605f~~~~~~~~RDJX8QBHPPMCGMD7YJQGYPD2
> > ....
> > 163209114129 /mnt/scratch/2/dbc/5459605f~~~~~~~~U820IYQFKS8A6QYCC8HU3ZBX
> > 292057960758 /mnt/scratch/0/dcc/54596070~~~~~~~~9BUH5D5PZTGAC8BT1YL77OZ0
> > ...
> > 292057960769 /mnt/scratch/0/dcc/54596070~~~~~~~~DAO78GAAFNUZU8PH7Q0UZNRH
> > 1395864555809 /mnt/scratch/1/e60/54596103~~~~~~~~GEMXGHYNREW409N7W9INBMVA
> > .....
> > 1395864555841 /mnt/scratch/1/e60/54596103~~~~~~~~9XPK9FWHCE21AJ3EN023DU47
> > 1653562593576 /mnt/scratch/5/e79/5459611c~~~~~~~~BSBZ6EUCT9HOIRQPMFZDVPQ5
> > .....
> > 1653562593601 /mnt/scratch/5/e79/5459611c~~~~~~~~6QY1SO8ZGGNQESAGXSB3G3DH
> > $
> > 
> > xfs_db> convert inode 163209114099 agno
> > 0x26 (38)
> > xfs_db> convert inode 163209114099 agino
> > 0x571f3 (356851)
> > xfs_db> convert inode 163209114129 agino
> > 0x57211 (356881)
> > xfs_db> agi 38
> > xfs_db> a root
> > xfs_db> a ptrs[2]
> > xfs_db> p
> > ....
> > recs[1-234] = [startino,freecount,free]
> > ......
> > 228:[356352,0,0] 229:[356416,0,0] 230:[356512,0,0] 231:[356576,0,0]
> > 232:[356672,0,0] 233:[356736,0,0] 234:[356832,14,0xfffc000000000000]
> > 
> > So the first contiguous inode range they all fall into the partial final record
> > in the AG.
> > 
> > xfs_db> convert inode 292057960758 agino
> > 0x2d136 (184630)
> > .....
> > 155:[184544,0,0] 156:[184608,30,0xfffffffc00000000]
> > 
> > Same.
> > 
> > xfs_db> convert inode 1395864555809 agino
> > 0x2d121 (184609)
> > .....
> > 155:[184544,0,0] 156:[184608,30,0xfffffffc00000000]
> > 
> > Same.
> > 
> > xfs_db> convert inode 1653562593576 agino
> > 0x2d128 (184616)
> > ....
> > 155:[184544,0,0] 156:[184608,30,0xfffffffc00000000]
> > 
> > Same.
> > 
> > So they are all falling into the last btree record in the AG, and so
> > appear to have been skipped as a result of the same issue. At least
> > that gives me something to look at.
> > 
> 
> Interesting, though just to note... is it possible this is related to
> records with free inodes?

Oh, definitely possible - I haven't ruled that out yet. However, I
would have expected such an issue ot manifest itself during xfstests
(e.g. xfs/068) where random files are removed from the filesystem
and so leaving fre inodes in the inobt....

> If this is a prepopulated fs for the purpose
> of this test, it's conceivable that there's only a small set of such
> records in the fs. The other records in your snippets here are fully
> allocated, but of course this is only a small snippet of a larger set of
> data.

Right, they are the only partially allocated chunks in the AGs in
question, but the other 496 AGs all have partial inode chunks as
their last records, too, and they have dumped correctly.

> It also might be interesting to know whether this repeats without the
> last patch in the series. IIRC that one seemed to have the most
> potential impact on the overall algorithm (by changing loop iteration
> logic, etc.). Just a thought.

I'll try that, but the missing files don't seem aligned to the
record itself, nor is it consistent with the free inodes in the
record, so it's not an obvious loop start/end issue. I'll just have
to dig in and look at it more closely.

Thanks for the musings and thoughts - I'll have to narrow down the
failure first to see if I can trigger it easily...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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