On Thu, Sep 14, 2023 at 11:07:43PM +0800, Anand Jain wrote: > This patch introduces a new configuration file parameter, POST_MKFS_CMD, > which, when set, will run immediately it after the mkfs command for the > FSTYP btrfs. > > For example: > POST_MKFS_CMD="btrfstune -m" > > Currently, only btrfstune's '-m' option is tested. However, there may be > more btrfstune options, so having this parameter as a config makes sense. > Additionally, there can be other commands besides btrfstune. > > The mkfs helper functions in common/rc passes the SCRATCH_DEV as an argument > to the set POST_MKFS_CMD, which may not be compatible with other configurable > commands in the future. However, as of now, since those usecases are still > unknown, we can modify it later. > > Signed-off-by: Anand Jain <anand.jain@xxxxxxxxxx> In general, we've put filesystem specific post-mkfs commands inside the filesystem specific mkfs function. See _scratch_mkfs_xfs() for example. If we want to test TB scale scratch filesystems without requiring ENOSPC tests to fill TBs of disk space, we set LARGE_SCRATCH_DEV. This causes the mkfs function to do the post-mkfs creation of a hidden file that consumes all but 50GB of space via fallocate (by calling _setup_large_xfs_fs()). Hence filesystem filling tests don't spend forever filling the filesystem, and no code outside of XFS specific functions need to care that this hidden file exists.... Given that the use case here is to issue filesystem specific commands rather than generic setup commands needed for all filesystems, I think it would be better to encapsulate it inside the btrfs specific mkfs implementation.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
