Re: [PATCH] common/config: Fix use of MKFS_OPTIONS

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

On Sun, Jun 26, 2022 at 08:47:08AM +1000, Dave Chinner wrote:
> > If we want to go down that approach, perhaps another approach would be
> > to specify the desired blocksize diretly in the fs config.  Something
> > like "FS_BLOCK_SIZE=1024"?  We can then have the fs-specific mkfs
> > commands translate that into the appropriate "-b 1024" or whatever
> > else might be appropriate for a particular file system.  And then
> > tests that want to override the block size can just override
> > FS_BLOCK_SIZE and then the _mkfs function can use it as appropriate.
> 
> This is the right way to fix the problem.
> 
> My plan was that once there was a single point of checking of
> MKFS_OPTIONS, I'd use that to extract the default value ifor the
> entire fstests run and convert everything else to use it. And then
> add config section support for the variable so that it can easily be
> specified on a config section by section basis.

Nice, that sounds like a good way to go.

And if we start down this path, for those file systems that support a
clustered allocation mode, what I'd then propose adding is a
FS_CLUSTER_SIZE parameter, so that the cluster size could be specified
in the config, hich could then get translated by the _mkfs_XXX
function into the appropriate mkfs option --- AND, so that generic
tests that are testing quota can just check the value of
$FS_CLUSTER_SIZE, and if it's set, use that to determine the
granularity of quota tracking.

This avoids having tests need to use fs-specific tools (such as
dumpe2fs) to determine if (a) clustered allocation is enabled, and (b)
what the cluster size is.

More generally, for any file system feature which is supported by more
than one file system[1], instead of explicitly specifying it via
MKFS_OPTIONS and/or MOUNT_OPTION, we could specify it abstractly,
which will make it easier for those tests who either need to override
that setting, or test to see what that setting might be.  This should
allow us to reduce the number of instances of "case $FSTYPE ..." in
tests/generic/*, which would be a very good thing.

[1] Examples of file system features that could use this include
fscrypt, case folding and maybe DAX.  We're mostly doing this for
external log devices already.

					- Ted