From: "Darrick J. Wong" <djwong@kernel.org>
To: Chandan Babu R <chandan.babu@oracle.com>
Cc: fstests@vger.kernel.org, zlang@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/4] xfs/270: Fix ro mount failure when nrext64 option is enabled
Date: Mon, 6 Jun 2022 08:31:43 -0700 [thread overview]
Message-ID: <Yp4d34D2lMqaNfVr@magnolia> (raw)
In-Reply-To: <20220606124101.263872-2-chandan.babu@oracle.com>
On Mon, Jun 06, 2022 at 06:10:58PM +0530, Chandan Babu R wrote:
> With nrext64 option enabled at run time, the read-only mount performed by the
> test fails because,
> 1. mkfs.xfs would have calculated log size based on reflink being enabled.
> 2. Clearing the reflink ro compat bit causes log size calculations to yield a
> different value.
> 3. In the case where nrext64 is enabled, this causes attr reservation to be
> the largest among all the transaction reservations.
> 4. This ends up causing XFS to require a larger ondisk log size than that
> which is available.
>
> This commit fixes the problem by setting features_ro_compat to the value
> obtained by the bitwise-OR of features_ro_compat field with 2^31.
>
> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> ---
> tests/xfs/270 | 16 ++++++++++++++--
> tests/xfs/270.out | 1 -
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/tests/xfs/270 b/tests/xfs/270
> index 0ab0c7d8..f3796691 100755
> --- a/tests/xfs/270
> +++ b/tests/xfs/270
> @@ -27,8 +27,20 @@ _scratch_mkfs_xfs >>$seqres.full 2>&1
> # set the highest bit of features_ro_compat, use it as an unknown
> # feature bit. If one day this bit become known feature, please
> # change this case.
> -_scratch_xfs_set_metadata_field "features_ro_compat" "$((2**31))" "sb 0" | \
> - grep 'features_ro_compat'
> +ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0")
> +ro_compat=${ro_compat##0x}
> +ro_compat="16#"${ro_compat}
> +ro_compat=$(($ro_compat|16#80000000))
I guess I just learned a ^^^^^ new bashism today.
> +ro_compat=$(_scratch_xfs_set_metadata_field "features_ro_compat" "$ro_compat" \
> + "sb 0" | grep 'features_ro_compat')
> +
> +ro_compat=${ro_compat##features_ro_compat = 0x}
> +ro_compat="16#"${ro_compat}
> +ro_compat=$(($ro_compat&16#80000000))
> +if (( $ro_compat != 16#80000000 )); then
> + echo "Unable to set most significant bit of features_ro_compat"
> +fi
Thanks for the fix,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> +
>
> # rw mount with unknown ro-compat feature should fail
> echo "rw mount test"
> diff --git a/tests/xfs/270.out b/tests/xfs/270.out
> index 0a8b3851..edf4c254 100644
> --- a/tests/xfs/270.out
> +++ b/tests/xfs/270.out
> @@ -1,5 +1,4 @@
> QA output created by 270
> -features_ro_compat = 0x80000000
> rw mount test
> ro mount test
> rw remount test
> --
> 2.35.1
>
next prev parent reply other threads:[~2022-06-06 15:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 12:40 [PATCH 0/4] Large extent counters tests Chandan Babu R
2022-06-06 12:40 ` [PATCH 1/4] xfs/270: Fix ro mount failure when nrext64 option is enabled Chandan Babu R
2022-06-06 15:31 ` Darrick J. Wong [this message]
2022-06-07 23:51 ` Dave Chinner
2022-06-08 8:22 ` Chandan Babu R
2022-06-06 12:40 ` [PATCH 2/4] common/xfs: Add helper to check if nrext64 option is supported Chandan Babu R
2022-06-06 15:30 ` Darrick J. Wong
2022-06-07 23:01 ` Dave Chinner
2022-06-08 8:15 ` Chandan Babu R
2022-06-06 12:41 ` [PATCH 3/4] xfs/547: Verify that the correct inode extent counters are updated with/without nrext64 Chandan Babu R
2022-06-06 15:40 ` Darrick J. Wong
2022-06-07 9:36 ` Chandan Babu R
2022-06-08 3:59 ` Zorro Lang
2022-06-08 9:11 ` Chandan Babu R
2022-06-06 12:41 ` [PATCH 4/4] xfs/548: Verify correctness of upgrading an fs to support large extent counters Chandan Babu R
2022-06-06 15:35 ` Darrick J. Wong
2022-06-07 9:47 ` Chandan Babu R
2022-06-07 15:20 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yp4d34D2lMqaNfVr@magnolia \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox