I'm curious why this is something that you care about this particular case? Historically, Red Hat (nor any other enterprise distribution) has supported changing or adding ext4 feature flags. What users were told to do was to create a new ext4 file system, and then copy the files (or do a backup/restore) to the new file system. Over a decade ago, when I was at Google, we did do a transition of file sytems from ext2 to ext4 (in no-journal mode) for all files stored in our cluster file systems. Our experience for our partcular workload is that the performance delta between an existing file system that was formatted w/o extents, and uninit_bg, and then converted to "ext4" using tune2fs, was roughly half the performance improvement of a file system that was freshly formatted to use ext4 once the file system was filled to roughly the same level, so that file system aging wastaken into account. So users who do the conversion won't get the full benefits of ext4. Also, the exact set of file system features that we changed was different from from what you are testing. I'd also note that this test is just filling a 1G file system, then changing the file system features, and then running fsck on the file system, and then trying to mount the file system. This isn't actually a very exhaustive test of doing a "conversion". If you really want to do a "coversion" test, what I'd recommend is to fill the TEST_DEV to be about 50% full, and then make the changes to the file system features, and then running the xfstests using the ext4 file system type without SCRATCH_DEV being set up. This would do a much better job of testing this case, without needing to add a new test to xfstest that to be honest, isn't really all that effective at testing this case. What did we do, 10+ year ago? Well, we ran xfstests using the a file system config[1] that didn't have flex_bg set, since that's one of the primary differences when using a "converted" file system. We then using tune2fs to convert 1% of the file systems in a single failure domain of the cluster file system, and watched looking for potential problems, and measuring for any performances gains (or losses). We then gradually increased the percentage of file systems converted to 2%, 5%, etc which is considered best practice[2] when doing this kind of feature rollout. [1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/root/fs/ext4/cfg/ext3conv [2] https://books.google.com/books?id=81UrjwEACAAJ Cheers, - Ted
