Re: [PATCH v1] ext4: add test case 061 for ext3 to ext4 conversion

["Theodore Ts'o" <tytso@mit.edu>]

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