Hi Ted, Thanks for your reply. I learned a lot from the text. On Thu, Feb 20, 2025 at 11:16 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > 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. We had learned we did have customers insist on doing the conversion rather than creating a fresh new ext4 and copying files for some reason, so we hope our test can cover this use case. > 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. I'm curious why the TEST_DEV is about 50% full is more 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. > I'm wondering is the [1] ext4 config can be used to simulated a tune2fs converted ext3 fs? > [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 > Cheers, Boyang
