Re: [PATCH 3/3] ext4: implemet new ioctls to set and get superblock parameters

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

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