Linux XFS filesystem development
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Chandan Babu R <chandan.babu@oracle.com>
Cc: fstests@vger.kernel.org, zlang@kernel.org, david@fromorbit.com,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH V3 1/4] xfs/270: Fix ro mount failure when nrext64 option is enabled
Date: Wed, 22 Jun 2022 10:03:21 -0700	[thread overview]
Message-ID: <YrNLWX0gVnl/EYTD@magnolia> (raw)
In-Reply-To: <20220611111037.433134-2-chandan.babu@oracle.com>

On Sat, Jun 11, 2022 at 04:40:34PM +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.
> 
> This commit includes changes suggested by Dave Chinner to replace bashisms
> with invocations to inline awk scripts.
> 
> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> ---
>  tests/xfs/270     | 26 ++++++++++++++++++++++++--
>  tests/xfs/270.out |  1 -
>  2 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/xfs/270 b/tests/xfs/270
> index 0ab0c7d8..b740c379 100755
> --- a/tests/xfs/270
> +++ b/tests/xfs/270
> @@ -27,8 +27,30 @@ _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")
> +echo $ro_compat | grep -q -E '^0x[[:xdigit:]]$'
> +if [[ $? != 0  ]]; then
> +	echo "features_ro_compat has an invalid value."
> +fi
> +
> +ro_compat=$(echo $ro_compat | \
> +		    awk '/^0x[[:xdigit:]]+/ {

I think the double-braces around :xdigit: were the only changes between
v2 and v3, right?

If so,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D


> +				printf("0x%x\n", or(strtonum($1), 0x80000000))
> +			}')
> +
> +# write the new ro compat field to the superblock
> +_scratch_xfs_set_metadata_field "features_ro_compat" "$ro_compat" "sb 0" \
> +				> $seqres.full 2>&1
> +
> +# read the newly set ro compat filed for verification
> +new_ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0" \
> +						2>/dev/null)
> +
> +# verify the new ro_compat field is correct.
> +if [ $new_ro_compat != $ro_compat ]; then
> +	echo "Unable to set new features_ro_compat. Wanted $ro_compat, got $new_ro_compat"
> +fi
>  
>  # 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
> 

  reply	other threads:[~2022-06-22 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-11 11:10 [PATCH V3 0/4] Large extent counters tests Chandan Babu R
2022-06-11 11:10 ` [PATCH V3 1/4] xfs/270: Fix ro mount failure when nrext64 option is enabled Chandan Babu R
2022-06-22 17:03   ` Darrick J. Wong [this message]
2022-06-11 11:10 ` [PATCH V3 2/4] common/xfs: Add helper to check if nrext64 option is supported Chandan Babu R
2022-06-11 11:10 ` [PATCH V3 3/4] xfs: Verify that the correct inode extent counters are updated with/without nrext64 Chandan Babu R
2022-06-11 11:10 ` [PATCH V3 4/4] xfs: Verify correctness of upgrading an fs to support large extent counters Chandan Babu R
2022-06-22 17:02 ` [PATCH V3 0/4] Large extent counters tests 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=YrNLWX0gVnl/EYTD@magnolia \
    --to=djwong@kernel.org \
    --cc=chandan.babu@oracle.com \
    --cc=david@fromorbit.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