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

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

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