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....
IMO, making it configurable and generic would also benefit other filesystems. For instance, the XFS filesystem could set it to 'POST_MKFS_CMD="xfs_admin -p"' or something similar ? The design choice here is to create an open and configurable command variable. This is because we have several commands and options that we need to test, and it wouldn't be practical to hardcode them. Any comments would be appreciated. I thought I would check again; I don't mind hardcoding it to a command specific to btrfs only if you still think it wouldn't be useful otherwise." Thanks, Anand
