On Thu, Sep 11, 2025 at 03:40:19PM -0700, Darrick J. Wong wrote: > > What's the difference between _FL_FEATURES and _FL_EDIT_FEATURES? We have three sets of _FL_FEATURES allows the user to set the features via: __u32 feature_compat; __u32 feature_incompat; __u32 feature_ro_compat; ... while _FS_EDIT_FEATURES allows the user to set or clear specific feature or feature(s) using these fields: __u32 set_feature_compat_mask; __u32 set_feature_incompat_mask; __u32 set_feature_ro_compat_mask; __u32 clear_feature_compat_mask; __u32 clear_feature_incompat_mask; __u32 clear_feature_ro_compat_mask; I originally only implemented _FS_EDIT_EFATURES but it turns out that given how tune2fs() and e2p_edit_feateurs2() was implemented, _FS_FEATURES was a lot more convenient. But I kept _FS_EDIT_FEATURES in case some other users wanted an easy way to, say, "just enable feature X" using a single ioctl. > > +#define EXT4_TUNE_CLEAR_COMPAT_SUPP (0) > > +#define EXT4_TUNE_CLEAR_INCOMPAT_SUPP (0) > > +#define EXT4_TUNE_CLEAR_RO_COMPAT_SUPP \ > > + (EXT4_FEATURE_RO_COMPAT_LARGE_FILE | \ > > + EXT4_FEATURE_RO_COMPAT_DIR_NLINK | \ > > + EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE | \ > > + EXT4_FEATURE_RO_COMPAT_PROJECT) > > Is it actually safe to clear these without scanning the filesystem to > make sure nobody's using these features? Hmm.... probably not. For some of these features, tune2fs will issue a "pleas run e2fsck -f" before mounting the file system. All of these featrues tune2fs will allow being cleared on a mounted file system, but looking at this more closely, I probably *shouldn't* have allowed tune2fs to remove the feature wile the file system is mounted. (For example, tune2fs -O ^project" will try to clear they project quota inode even if the file system is mounted, hilarity would soon follow...) - Ted