On 26 Jul 2021 at 22:49, Darrick J. Wong wrote: > On Mon, Jul 26, 2021 at 12:13:13PM +0530, Chandan Babu R wrote: >> _scratch_do_mkfs constructs a mkfs command line by concatenating the values of >> 1. $mkfs_cmd >> 2. $MKFS_OPTIONS >> 3. $extra_mkfs_options >> >> The corresponding mkfs command line fails if $MKFS_OPTIONS enables either >> reflink or rmapbt feature. The failure occurs because the test tries to create >> a filesystem with realtime device enabled. In such a case, _scratch_do_mkfs() >> will construct and invoke an mkfs command line without including the value of >> $MKFS_OPTIONS. >> >> To prevent such silent failures, this commit causes the test to exit if it >> detects either reflink or rmapbt feature being enabled. > > Er, what combinations of mkfs.xfs and MKFS_OPTIONS cause this result? > What kind of fs configuration comes out of that? With MKFS_OPTIONS set as shown below, export MKFS_OPTIONS="-m reflink=1 -b size=1k" _scratch_do_mkfs() invokes mkfs.xfs with both realtime and reflink options enabled. Such an invocation of mkfs.xfs fails causing _scratch_do_mkfs() to ignore the contents of $MKFS_OPTIONS while constructing and invoking mkfs.xfs once again. This time, the fs block size will however be set to 4k (the default block size). At the beginning of the test we would have obtained the block size of the filesystem as 1k and used it to compute the size of the realtime device required to overflow realtime bitmap inode's max pseudo extent count. Invocation of xfs_growfs (made later in the test) ends up succeeding since a 4k fs block can accommodate more bits than a 1k fs block. > > Eventually, the plan is to support rmap[1] and reflink[2] on the > realtime device, at which point this will have to be torn out and a > better solution found. > > --D > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=realtime-rmap > [2] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=realtime-reflink > -- chandan
