This patch introduces new configuration file parameters,
POST_SCRATCH_MKFS_CMD and POST_SCRATCH_POOL_MKFS_CMD.
Usage example:
POST_SCRATCH_MKFS_CMD="btrfstune -m"
POST_SCRATCH_POOL_MKFS_CMD="btrfstune -m"
Can't we add extra options for mkfs.btrfs to support metadata uuid at
mkfs time?
We already support quota and all other features, I think it would be
much easier to implement metadata_uuid inside mkfs.
If this feature is only for metadata_uuid, then I really prefer to do it
inside mkfs.btrfs.
Thanks for the comments.
The use of btrfstune -m is just an example; any other command,
function, or script can be assigned to the variable POST_SCRATCH_xx.
The last time I tried something like this, I got strong objection from
some guy in the XFS community.
Just good luck if you can have a better chance.
As another guy in the XFS community, I also don't understand why this
can't be accomplished with a _scratch_mkfs_btrfs helper that runs the
real mkfs tool and then tunes the resulting fs. Is it significant for
bug finding to be able to run an entire separate fstests config with
this config? Versus writing a targeted exerciser for the -m case? >
Is there some reason why the exact command needs to be injected via
environment variables? Or, why can't mkfs.btrfs do whatever "btrfstune
-m" does?
I suppose the problem there is that mkfs.btrfs won't itself create a
filesystem with the metadata_uuid field that doesn't match the other
uuid?
Thanks for the feedback. mkfs.btrfs might also include an option for
btrfstune -m operations during file system creation. While this may
not be the primary use case for mkfs.btrfs, it can be useful for
running fstests. If these changes are integrated, we can use
MKFS_OPTIONS to run the entire fstests suite, potentially making
this patch unnecessary. Let's see how it unfolds.
I made POST_MKFS_CMD configurable in the config file because we
don't have to patch fstests if we need to test with a different
operation post mkfs.
Thanks, Anand
