From: "Darrick J. Wong" <djwong@kernel.org>
To: Filipe Manana <fdmanana@kernel.org>
Cc: zlang@redhat.com, linux-xfs@vger.kernel.org,
fstests@vger.kernel.org,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 05/12] generic/562: handle ENOSPC while cloning gracefully
Date: Mon, 18 Nov 2024 16:31:31 -0800 [thread overview]
Message-ID: <20241119003131.GT9438@frogsfrogsfrogs> (raw)
In-Reply-To: <CAL3q7H5KjvXsXzt4n0XP1FTUt=A5cKom7p+dGD6GG-iL7CyDXQ@mail.gmail.com>
On Tue, Nov 19, 2024 at 12:17:56AM +0000, Filipe Manana wrote:
> On Mon, Nov 18, 2024 at 11:03 PM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > This test creates a couple of patterned files on a tiny filesystem,
> > fragments the free space, clones one patterned file to the other, and
> > checks that the entire file was cloned.
> >
> > However, this test doesn't work on a 64k fsblock filesystem because
> > we've used up all the free space reservation for the rmapbt, and that
> > causes the FICLONE to error out with ENOSPC partway through. Hence we
> > need to detect the ENOSPC and _notrun the test.
> >
> > That said, it turns out that XFS has been silently dropping error codes
> > if we managed to make some progress cloning extents. That's ok if the
> > operation has REMAP_FILE_CAN_SHORTEN like copy_file_range does, but
> > FICLONE/FICLONERANGE do not permit partial results, so the dropped error
> > codes is actually an error.
> >
> > Therefore, this testcase now becomes a regression test for the patch to
> > fix that.
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > tests/generic/562 | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/tests/generic/562 b/tests/generic/562
> > index 91360c4154a6a2..62899945003513 100755
> > --- a/tests/generic/562
> > +++ b/tests/generic/562
> > @@ -15,6 +15,9 @@ _begin_fstest auto clone punch
> > . ./common/filter
> > . ./common/reflink
> >
> > +test "$FSTYP" = "xfs" && \
> > + _fixed_by_kernel_commit XXXXXXXXXX "xfs: don't drop errno values when we fail to ficlone the entire range"
> > +
> > _require_scratch_reflink
> > _require_test_program "punch-alternating"
> > _require_xfs_io_command "fpunch"
> > @@ -48,8 +51,11 @@ while true; do
> > done
> >
> > # Now clone file bar into file foo. This is supposed to succeed and not fail
> > -# with ENOSPC for example.
> > -_reflink $SCRATCH_MNT/bar $SCRATCH_MNT/foo >>$seqres.full
> > +# with ENOSPC for example. However, XFS will sometimes run out of space.
> > +_reflink $SCRATCH_MNT/bar $SCRATCH_MNT/foo >>$seqres.full 2> $tmp.err
> > +cat $tmp.err
> > +grep -q 'No space left on device' $tmp.err && \
> > + _notrun "ran out of space while cloning"
>
> This defeats the original purpose of the test, which was to verify
> btrfs didn't fail with -ENOSPC (or any other error).
>
> If XFS has an ENOSPC issue in some cases, and it's not fixable, why
> not make it _notrun only if it's XFS that is being tested?
Ok, will do. In the case of xfs, we don't let you share data if the
allocation group it's in is more than about 90% full.
--D
> Thanks.
>
>
> >
> > # Unmount and mount the filesystem again to verify the operation was durably
> > # persisted.
> >
> >
>
next prev parent reply other threads:[~2024-11-19 0:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 23:01 [PATCHSET] fstests: random fixes for v2024.11.17 Darrick J. Wong
2024-11-18 23:01 ` [PATCH 01/12] generic/757: fix various bugs in this test Darrick J. Wong
2024-11-21 9:56 ` Zorro Lang
2024-11-21 10:05 ` Christoph Hellwig
2024-11-21 10:13 ` Christoph Hellwig
2024-11-21 10:52 ` Christoph Hellwig
2024-11-21 16:33 ` Darrick J. Wong
2024-11-21 17:19 ` Darrick J. Wong
2024-11-22 12:35 ` Christoph Hellwig
2024-11-21 12:28 ` Brian Foster
2024-11-21 13:12 ` Christoph Hellwig
2024-11-21 14:11 ` Brian Foster
2024-11-22 12:31 ` Christoph Hellwig
2024-11-22 13:49 ` Brian Foster
2024-11-22 16:13 ` Darrick J. Wong
2024-11-22 16:20 ` Christoph Hellwig
2024-11-22 16:33 ` Brian Foster
2024-11-22 16:37 ` Darrick J. Wong
2024-11-21 16:04 ` Darrick J. Wong
2024-11-22 12:34 ` Christoph Hellwig
2024-11-18 23:01 ` [PATCH 02/12] xfs/113: fix failure to corrupt the entire directory Darrick J. Wong
2024-11-18 23:02 ` [PATCH 03/12] xfs/508: fix test for 64k blocksize Darrick J. Wong
2024-11-18 23:02 ` [PATCH 04/12] common/rc: capture dmesg when oom kills happen Darrick J. Wong
2024-11-18 23:02 ` [PATCH 05/12] generic/562: handle ENOSPC while cloning gracefully Darrick J. Wong
2024-11-19 0:17 ` Filipe Manana
2024-11-19 0:31 ` Darrick J. Wong [this message]
2024-11-25 5:18 ` Darrick J. Wong
2024-11-18 23:02 ` [PATCH 06/12] xfs/163: skip test if we can't shrink due to enospc issues Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 07/12] xfs/009: allow logically contiguous preallocations Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 08/12] generic/251: use sentinel files to kill the fstrim loop Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 09/12] generic/251: constrain runtime via time/load/soak factors Darrick J. Wong
2024-11-19 1:45 ` Dave Chinner
2024-11-19 6:13 ` Christoph Hellwig
2024-11-19 15:45 ` Darrick J. Wong
2024-11-19 21:04 ` Dave Chinner
2024-11-19 21:16 ` Darrick J. Wong
2024-11-19 15:50 ` Darrick J. Wong
2024-11-18 23:03 ` [PATCH 10/12] common/rc: _scratch_mkfs_sized supports extra arguments Darrick J. Wong
2024-11-18 23:04 ` [PATCH 11/12] xfs/157: do not drop necessary mkfs options Darrick J. Wong
2024-11-21 10:03 ` Zorro Lang
2024-11-18 23:04 ` [PATCH 12/12] xfs/157: fix test failures when MKFS_OPTIONS has -L options Darrick J. Wong
2024-11-21 10:17 ` Zorro Lang
2024-11-21 17:19 ` 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=20241119003131.GT9438@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fdmanana@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-xfs@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