On Wed, May 16, 2018 at 3:00 AM, Daniel Kiper <dkiper@xxxxxxxxxxxx> wrote: > On Tue, May 15, 2018 at 02:55:55PM -0500, Eric Sandeen wrote: >> The sparse inode metadata format became a mkfs.xfs default in >> xfsprogs-4.16.0, and such filesystems are now rejected by grub as >> containing an incompatible feature. >> >> In essence, this feature allows xfs to allocate inodes into fragmented >> freespace. (Without this feature, if xfs could not allocate contiguous >> space for 64 new inodes, inode creation would fail.) >> >> In practice, the disk format change is restricted to the inode btree, >> which as far as I can tell is not used by grub. If all you're doing >> today is parsing a directory, reading an inode number, and converting >> that inode number to a disk location, then ignoring this feature >> should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED >> >> I did some brief testing of this patch by hacking up the regression >> tests to completely fragment freespace on the test xfs filesystem, and >> then write a large-ish number of inodes to consume any existing >> contiguous 64-inode chunk. This way any files the grub tests add and >> traverse would be in such a fragmented inode allocation. Tests passed, >> but I'm not sure how to cleanly integrate that into the test harness. >> >> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > > Eric, thank you for posting the patch. LGTM. > > Chris, may I ask you to test it and add your "Tested-by:" if it works? Fedora openQA (which caught the bug) now passes. I did a separate test making sure sparse inode feature is enabled and grub-probe, grub-install, grub-mkconfig report no problem. So yeah feel free to Tested-by to me. -- Chris Murphy -- 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
