From: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
To: Zorro Lang <zlang@redhat.com>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>
Subject: Re: [PATCH 1/2] xfs/270: only check new_ro_compat value when mkfs.xfs supports nrext64 feature
Date: Tue, 5 Jul 2022 05:46:50 +0000 [thread overview]
Message-ID: <62C3DE8F.5030306@fujitsu.com> (raw)
In-Reply-To: <20220704154242.sfq7ekeprovowcr2@zlang-mailbox>
on 2022/07/04 23:42, Zorro Lang wrote:
> On Mon, Jun 27, 2022 at 10:30:02PM +0800, Yang Xu wrote:
>> Currently, this case fails on old xfsprogs as below:
>> +/var/lib/xfstests/tests/xfs/270: line 51: [: !=: unary operator expected
>>
>> Getting ro_compat value will report the following error after setting new ro_compat
>> value:
>> +cache_purge: shake on cache 0x56033fde4920 left 1 nodes!?
>> +cache_purge: shake on cache 0x56033fde4920 left 1 nodes!?
>> +cache_zero_check: refcount is 1, not zero (node=0x56033fdf9110
>>
>> Old xfsprogs miss a bugfix
>> f4afdcb0ad ("xfs_db: clean up the salvage read callsites in set_cur()").
>>
>> Here we skip the get step of new ro_comap value when nrext64 feature is supported.
>> Also will add a new test to cover this xfsprog bug.
>>
>> Signed-off-by: Yang Xu<xuyang2018.jy@fujitsu.com>
>> ---
>> tests/xfs/270 | 23 ++++++++++++++++-------
>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/tests/xfs/270 b/tests/xfs/270
>> index b740c379..5ff83ead 100755
>> --- a/tests/xfs/270
>> +++ b/tests/xfs/270
>> @@ -22,6 +22,10 @@ _require_scratch_nocheck
>> # Only V5 XFS disallow rw mount/remount with unknown ro-compat features
>> _require_scratch_xfs_crc
>>
>> +nrext64_supported=0
>> +_scratch_mkfs_xfs_supported -m crc=1 -i nrext64> /dev/null 2>&1&& \
>> + nrext64_supported=1
>> +
>> _scratch_mkfs_xfs>>$seqres.full 2>&1
>>
>> # set the highest bit of features_ro_compat, use it as an unknown
>> @@ -43,13 +47,18 @@ ro_compat=$(echo $ro_compat | \
>> _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
>
> My personal opinion is -- change above line as:
> if [ "$new_ro_compat" != "$ro_compat" ]
> to avoid the bash syntax error. Then the failure (on old xfsprogs) correspond
> to a known xfsprogs bug. That's good enough.
Ok, will do it on v2. Thanks.
Best Regards
Yang Xu
>
> Thanks,
> Zorro
>
>> - echo "Unable to set new features_ro_compat. Wanted $ro_compat, got $new_ro_compat"
>> +# Indeed, xfsprogs has a bug here and fixed by commit f4afdcb
>> +# ("xfs_db: clean up the salvage read callsites in set_cur()")
>> +# Here, we use nrext64 feature as a proxy.
>> +if [ $nrext64_supported -eq 1 ]; then
>> + # 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
>> fi
>>
>> # rw mount with unknown ro-compat feature should fail
>> --
>> 2.27.0
>>
>
prev parent reply other threads:[~2022-07-05 5:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 14:30 [PATCH 1/2] xfs/270: only check new_ro_compat value when mkfs.xfs supports nrext64 feature Yang Xu
2022-06-27 14:30 ` [PATCH 2/2] xfs/082: Add xfs_db get value regression test Yang Xu
2022-07-04 17:57 ` Zorro Lang
2022-07-05 7:23 ` xuyang2018.jy
2022-07-04 9:43 ` [PATCH 1/2] xfs/270: only check new_ro_compat value when mkfs.xfs supports nrext64 feature xuyang2018.jy
2022-07-04 15:42 ` Zorro Lang
2022-07-05 5:46 ` xuyang2018.jy [this message]
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=62C3DE8F.5030306@fujitsu.com \
--to=xuyang2018.jy@fujitsu.com \
--cc=fstests@vger.kernel.org \
--cc=zlang@redhat.com \
/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