RFC: Add support for filesystem-specific features
ClosedPublic

Authored by aferraris on Jun 19 2019, 3:43 PM.

Details

Summary

In some cases, it may be necessary to create a filesystem with specific features enabled/disabled.

This PR is a proposal of an API extension, making it possible to create filesystems this way. It does so by introducing a new m_Features member variable and the createWithFeatures() function to the FileSystem base class. The latter function is implemented for the btrfs and ext2/3/4 filesystems.

Additionnally, the CreateFileSystemJob has been modified to enable creating/formatting filesystems with specific features enabled.

Please note this PR should be considered *work in progress*: most filesystems lack a proper implementation, and it has not been thoroughly tested. However, it is open for discussion, and comments are more than welcome.

Diff Detail

Repository
R16 KPMCore
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
aferraris requested review of this revision.Jun 19 2019, 3:43 PM
aferraris created this revision.
aferraris added inline comments.Jun 19 2019, 3:45 PM
src/jobs/createfilesystemjob.cpp
60

We could use a createWithFeaturesAndLabel() function, I just prefered going for the simplest approach for now.

-i bytes-per-inodeI am a bit worried that this API would be hard to use from GUI clients. Although in general, I think direction is good.

In this patch features are just passed as QStringList. So the logic of what features are support would have to reside in the client. I think it would be better if you can query kpmcore FileSystem for extra features that it supports. Then it would be easier to implement them in GUI.

E.g. btrfs would return skinny-metadata and a few others, similarly for ext4.

By the way some filesystems have other features passed through other command line flags. Do you think we can add support for those too? For mke2fs you implemented -O feature but some other fs specific features can be specified using other flags, like -C cluster-size. (Some people are actually interested in block size in FAT fs https://bugs.kde.org/show_bug.cgi?id=342178). Although, these "features" need an extra input... So they would need some richer API then just passing it as string.

aferraris updated this revision to Diff 62321.EditedJul 22 2019, 4:39 PM
  • fs: Change type for filesystem-specific features
  • fs: Implement a way for the application to query fs features

These patches allow the handling of "complex" filesystem features requiring an argument, and can also provide the application with a list of features supported by a specific filesystem.

Implementation is provided only for "binary" (enabled or not) features of btrfs and ext2/3/4, but upcoming changes will address several complex features, such as cluster-size in ext2/3/4, or FAT block size.

stikonas added inline comments.Jul 22 2019, 7:42 PM
src/fs/filesystem.h
64

Can we turn it into a proper class?

Filesystem features sound quite general, so I imagine it might be required to modify/extend structure of this class.

  1. I would put class feature into fs/feature.h
  2. Please d-pointerize the class (see FileSystemPrivate for example). That would help to modify the class without breaking C++ ABI.
aferraris updated this revision to Diff 63352.Aug 8 2019, 12:15 PM

This new version adds a few improvements:

  • the FileSystem::Feature class has been moved to a new FSFeature top-level class, as requested
  • the API has been made simpler by letting the existing create and createWithLabel functions handle the filesystem-specific features, removing the need for a createWithFeatures function
  • a bug has been fixed in the parsing of available features for btrfs

Finally, this patchset has been thoroughly tested for ext4 and btrfs filesystems.
If everything is OK, I can add support for fat32 blocksize before merging.

stikonas accepted this revision.Aug 8 2019, 8:27 PM

Finally, this patchset has been thoroughly tested for ext4 and btrfs filesystems.
If everything is OK, I can add support for fat32 blocksize before merging.

Thanks for updating the patch. I think everything is fine. Feel free to merge
(if you can add fat blocksize before merging).

This revision is now accepted and ready to land.Aug 8 2019, 8:27 PM
aferraris updated this revision to Diff 63419.Aug 9 2019, 2:42 PM

This revision adds support for setting a custom block size on FAT12/16/32 filesystems.

btw, I'm not a kde developer, so you'll probably have to merge my changes yourself.

Hello here! Is there anything blocking this RFC? Reading the backlog, it seems that everything was good, but that was 6 months ago. Is there anything I can do to help this RFC move forward? Thanks!

Hello here! Is there anything blocking this RFC? Reading the backlog, it seems that everything was good, but that was 6 months ago. Is there anything I can do to help this RFC move forward? Thanks!

Oh, sorry for not merging it yet. I need @aferraris email to make a commit.

This revision was automatically updated to reflect the committed changes.

Thanks for merging!

Hmm, it looks like it breaks ABI, so we should have bumped kpmcore SOVERSION in this commit. I'll do that now.