RFE: moving btrfs from experimental to official Support

[jakobmoellerdev]

What should the feature do:

The feature aims to transition the support status of btrfs within TopoLVM from 'experimental' to 'officially supported'. This involves ensuring full compatibility with btrfs, rigorous testing under various scenarios specific to btrfs filesystems, and documentation updates to reflect this support. Additionally, it should address any known issues or limitations that were previously tagged as 'experimental'.

What is use case behind this feature:

Btrfs, being a filesystem that offers advanced features like snapshotting, compression, and subvolume management, is becoming increasingly popular among Linux users, especially in environments where data integrity and flexibility are paramount. For users and organizations that have adopted btrfs as their filesystem of choice, having official support from TopoLVM means they can fully leverage the features and performance optimizations of btrfs in their storage volumes managed by TopoLVM. This transition also signifies a commitment to the broader storage and filesystem community, showcasing TopoLVM's dedication to supporting a wide array of storage technologies and configurations. By moving btrfs to official support status, TopoLVM can attract a wider user base, foster community contributions, and enhance its utility in diverse environments.

[ushitora-anqou]

This involves ensuring full compatibility with btrfs, rigorous testing under various scenarios specific to btrfs filesystems, and documentation updates to reflect this support.

My understanding is that, to officially support btrfs, we'll need to add at least some E2E tests using storageclasses of fsType: btrfs. Do you have any plans for what else we need to do?

[jakobmoellerdev]

I agree. Ultimately I think we should think what we have for ext4/xfs. I believe in our current E2E tests we only test mainly with ext4 and do not have a big matrix for xfs. We can simply extend the matrix to test all E2E scenarios with both xfs and ext4.

[jakobmoellerdev]

I am mainly inquiring if this is something we want in the end and if it will be accepted to introduce more vectors like this in the test matrix (as this will increase the test amount significantly). If it is something we desire, I believe I can accomodate that.

[ushitora-anqou]

Thanks for your description. We'll be happy to merge this enhancement if you submit a PR.

We can simply extend the matrix to test all E2E scenarios with both xfs and ext4.

My (and my colleagues') concern is that it's not acceptable for the changes to make the E2E tests and CI much slower than they are now, since they are already relatively slow. Extending the E2E tests to the same extent as the current tests for xfs would be the best.

[jakobmoellerdev]

That makes sense for me for now, lets scope it so that btrfs has the same test scope as xfs. I think we should add an issue to investigate parallelizing the storage tests if that has not been done already. sequentially running these tests is not necessary imo and we have a lot of "monolith" tests that do everything at once.

[ushitora-anqou]

I agree with you. It seems that the current E2E tests don't enable ginkgo's -p option, so it might be worth a try:

topolvm/test/e2e/Makefile

Line 16 in 5675329

GINKGO_FLAGS :=

https://onsi.github.io/ginkgo/#spec-parallelization

[jakobmoellerdev]

Update here: btrfs is now included in E2E tests similarly to xfs. I think this sets it up for a soon to be upgrade from experimental support. Should we target this for resolution in the next minor?

[ushitora-anqou]

Yes! We'd like to move in that direction.