On Thu, Aug 17, 2017 at 02:34:40AM -0300, Ernesto A. Fernández wrote: > On Thu, Aug 17, 2017 at 10:00:42AM +1000, Dave Chinner wrote: > > On Wed, Aug 16, 2017 at 04:31:01PM -0300, Ernesto A. Fernández wrote: > > > xfs_repair, phase 3: > > > bad magic number febe in block 512 (14452) for directory inode 131 > > > > Hmmmm - that's a magic number for a non-crc DA node. Kinda implies > > that it ENOSPC'd in the middle of a tree split. > > > > Can you test on a CRC enabled filesystem and see if there are any > > other errors that are detected either at runtime or by repair? > > No other errors, no. > > > If it does fail, can youpost the full output of xfs_repair? > > Of course. I don't think it will be of much help though: > > > 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 > bad magic number 3ebe in block 506 (14446) for directory inode 67 Ok, so it's a specific change in tree size that is causing the problem. It's probably a tree height change opertaion.... > Perhaps this can be of some use: > > In my test I'm setting as many xattrs with 1k values as possible. If I > change that to 64k values this bug is no longer seen. Of course. Large xattrs are stored remote to the attribute tree, so each attribute is only consuming ~30-40 bytes in the attribute tree rather than 1k. > The cutoff seems to be when the name+value of the xattr are above 3072+1 > bytes. Which is exactly 75% of the attribute tree block size. i.e. the size that attribute data is stored remotely instead of in the tree itself. > This does not depend on the amount of free space of the > filesystem, so this is probably not just about the number of xattrs as I > first thought. Given it follows the block size, it smells of a btree level change going wrong. Haven't go ttime to look right now, but if you could look at the inode in xfs_db and print the state of the root attr fork and the root attr block header before running xfs_repair in the filesystem that would probably tell us.. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
