Re: [PATCH 3/3] xfs/530: Bail out if either of reflink or rmapbt is enabled

From: Chandan Babu R <chandanrlinux@gmail.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: fstests@vger.kernel.org, guaneryu@gmail.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs/530: Bail out if either of reflink or rmapbt is enabled
Date: Tue, 27 Jul 2021 10:15:27 +0530	[thread overview]
Message-ID: <87fsw0fjq0.fsf@garuda> (raw)
In-Reply-To: <20210726171916.GV559212@magnolia>

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