On Fri, Feb 21, 2025 at 01:06:04AM +0800, Boyang Xue wrote: > > 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. > > I'm curious why the TEST_DEV is about 50% full is more effective at > testing this case? The reason why this is useful is because we are starting with a file system that 50% of the space filled with files using indirect files, and when you run the tests, you are created and deleting files using extents. That's actualy not perfect. What we would want to do is to create ext2/ext3-style files using indirect block maps, that would then be mutated using fstress and fsx in parallel with files being created, mutated, and deleted using extent-mapped files. The basic idea is that you want to actually exercise *using* the file system after it is converted -- reading and writing files, allocating and dealocating blocks and inodes, after converting the file sytem -- and then making sure that the kernel doesn't crash or result in a corrupted file system. Your proposed test just fills the file system, unmounts it, uses tune2fs to add the extents feature flag, and then runs e2fsck on the file system, and then tries mounting the file system. That's pretty much guaranteed to work, since running fsck.ext4 on a file system that was originally created as ext3, with lots of indirect mapped files, and then adding the extent flag, essentially exercises *zero* new or different code paths. Cheers, - Ted
