From: "Darrick J. Wong" <djwong@kernel.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: Nirjhar Roy <nirjhar@linux.ibm.com>,
fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, ojaswin@linux.ibm.com,
zlang@kernel.org
Subject: Re: [PATCH v3 2/3] common/rc: Add a new _require_scratch_extsize helper function
Date: Fri, 22 Nov 2024 08:04:30 -0800 [thread overview]
Message-ID: <20241122160430.GZ9425@frogsfrogsfrogs> (raw)
In-Reply-To: <871pz4xvuu.fsf@gmail.com>
On Fri, Nov 22, 2024 at 12:22:41AM +0530, Ritesh Harjani wrote:
> Nirjhar Roy <nirjhar@linux.ibm.com> writes:
>
> > On 11/21/24 13:23, Ritesh Harjani (IBM) wrote:
> >> Nirjhar Roy <nirjhar@linux.ibm.com> writes:
> >>
> >>> _require_scratch_extsize helper function will be used in the
> >>> the next patch to make the test run only on filesystems with
> >>> extsize support.
> >>>
> >>> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> >>> Signed-off-by: Nirjhar Roy <nirjhar@linux.ibm.com>
> >>> ---
> >>> common/rc | 17 +++++++++++++++++
> >>> 1 file changed, 17 insertions(+)
> >>>
> >>> diff --git a/common/rc b/common/rc
> >>> index cccc98f5..995979e9 100644
> >>> --- a/common/rc
> >>> +++ b/common/rc
> >>> @@ -48,6 +48,23 @@ _test_fsxattr_xflag()
> >>> grep -q "fsxattr.xflags.*\[.*$2.*\]" <($XFS_IO_PROG -c "stat -v" "$1")
> >>> }
> >>>
> >>> +# This test requires extsize support on the filesystem
> >>> +_require_scratch_extsize()
> >>> +{
> >>> + _require_scratch
> >> _require_xfs_io_command "extsize"
> >>
> >> ^^^ Don't we need this too?
> > Yes, good point. I will add this in the next revision.
> >>
> >>> + _scratch_mkfs > /dev/null
> >>> + _scratch_mount
> >>> + local filename=$SCRATCH_MNT/$RANDOM
> >>> + local blksz=$(_get_block_size $SCRATCH_MNT)
> >>> + local extsz=$(( blksz*2 ))
> >>> + local res=$($XFS_IO_PROG -c "open -f $filename" -c "extsize $extsz" \
> >>> + -c "extsize")
> >>> + _scratch_unmount
> >>> + grep -q "\[$extsz\] $filename" <(echo $res) || \
> >>> + _notrun "this test requires extsize support on the filesystem"
> >> Why grep when we can simply just check the return value of previous xfs_io command?
> > No, I don't think we can rely on the return value of xfs_io. For ex,
> > let's look at the following set of commands which are ran on an ext4 system:
> >
> > root@AMARPC: /mnt1/test$ xfs_io -V
> > xfs_io version 5.13.0
> > root@AMARPC: /mnt1/test$ touch new
> > root@AMARPC: /mnt1/test$ xfs_io -c "extsize 8k" new
> > foreign file active, extsize command is for XFS filesystems only
> > root@AMARPC: /mnt1/test$ echo "$?"
> > 0
> > This incorrect return value might have been fixed in some later versions
> > of xfs_io but there are still versions where we can't solely rely on the
> > return value.
>
> Ok. That's bad, we then have to rely on grep.
> Sure, thanks for checking and confirming that.
You all should add CMD_FOREIGN_OK to the extsize command in xfs_io,
assuming that you've not already done that in your dev workspace.
--D
> -ritesh
>
next prev parent reply other threads:[~2024-11-22 16:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 5:09 [PATCH v3 0/3] Addition of new tests for extsize hints Nirjhar Roy
2024-11-21 5:09 ` [PATCH v3 1/3] common/rc,xfs/207: Add a common helper function to check xflag bits Nirjhar Roy
2024-11-21 17:20 ` Darrick J. Wong
2024-11-21 18:30 ` Nirjhar Roy
2024-11-21 5:09 ` [PATCH v3 2/3] common/rc: Add a new _require_scratch_extsize helper function Nirjhar Roy
2024-11-21 7:53 ` Ritesh Harjani
2024-11-21 18:33 ` Nirjhar Roy
2024-11-21 18:52 ` Ritesh Harjani
2024-11-22 16:04 ` Darrick J. Wong [this message]
2024-11-22 18:07 ` Nirjhar Roy
2024-11-22 18:44 ` Darrick J. Wong
2024-11-22 19:06 ` Nirjhar Roy
2024-11-21 5:09 ` [PATCH v3 3/3] generic: Addition of new tests for extsize hints Nirjhar Roy
2024-11-21 17:27 ` Darrick J. Wong
2024-11-21 18:34 ` Nirjhar Roy
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=20241122160430.GZ9425@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nirjhar@linux.ibm.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--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