From: Zorro Lang <zlang@kernel.org>
To: Filipe Manana <fdmanana@kernel.org>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] generic: add a test case for writes with prealloc extents beyond i_size
Date: Sun, 14 Jun 2026 23:24:40 +0800 [thread overview]
Message-ID: <ai7Fm0OzuKXV1zHw@zlang-mailbox> (raw)
In-Reply-To: <CAL3q7H7hCDQJxk1an8mk7030fb=qVdCeHaqza=H4DbCvWxtvrQ@mail.gmail.com>
On Sun, Jun 14, 2026 at 11:57:39AM +0100, Filipe Manana wrote:
> On Thu, May 28, 2026 at 11:27 AM <fdmanana@kernel.org> wrote:
> >
> > From: Filipe Manana <fdmanana@suse.com>
> >
> > Test writing into a file range containing prealloc extents beyond the current
> > i_size, with an unmount and mount after fallocate and the write, to verify
> > that the file data, size and extent layout were not lost.
> >
> > This used to fail on btrfs when not using the no-holes feature (which is
> > a default since btrfs-progs 5.15) before this recent kernel fix:
> >
> > 080ecbd05432 ("btrfs: mark file extent range dirty after converting prealloc extents")
> >
> > So in order to reproduce the failure when using an unpatched kernel and
> > a btrfs-progs >= 5.15, one must run the test with:
> >
> > MKFS_OPTIONS="-O ^no-holes"
> >
> > Signed-off-by: Filipe Manana <fdmanana@suse.com>
>
> Zorro, this is missing in the patches-in-queue branch (and for-next).
> Did you miss this?
Hi Filipe,
Sorry, I got this patch mixed up with another one -- 32b4dfff ("generic: add a
test case for fallocate i_size extension"). They have the same author, reviewer,
and case number, and even their commit logs look very similar. At first glance,
I mistakenly thought it was a patch I had already merged :-P
Thank you for pointing this out. I will test it and merge it into the
patches-in-queue branch right away, and it will be released next week
along with the others.
Thanks,
Zorro
>
> Thanks.
>
> > ---
> > tests/generic/796 | 54 +++++++++++++++++++++++++++++++++++++++++++
> > tests/generic/796.out | 10 ++++++++
> > 2 files changed, 64 insertions(+)
> > create mode 100755 tests/generic/796
> > create mode 100644 tests/generic/796.out
> >
> > diff --git a/tests/generic/796 b/tests/generic/796
> > new file mode 100755
> > index 00000000..c42a4722
> > --- /dev/null
> > +++ b/tests/generic/796
> > @@ -0,0 +1,54 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2026 SUSE S.A. All Rights Reserved.
> > +#
> > +# FS QA Test 796
> > +#
> > +# Test writing into a file range containing prealloc extents beyond the current
> > +# i_size, with an unmount and mount after fallocate and the write, to verify
> > +# that the file data, size and extent layout were not lost.
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto quick prealloc preallocrw fiemap
> > +
> > +. ./common/filter
> > +. ./common/punch # for _filter_fiemap
> > +
> > +_require_scratch
> > +_require_xfs_io_command "falloc" "-k"
> > +_require_xfs_io_command "fiemap"
> > +
> > +_fixed_by_fs_commit btrfs 080ecbd05432 \
> > + "btrfs: mark file extent range dirty after converting prealloc extents"
> > +
> > +_scratch_mkfs >>$seqres.full 2>&1
> > +_scratch_mount
> > +
> > +# The fiemap results in the golden output requires file allocations to align to
> > +# 1M boundaries.
> > +_require_congruent_file_oplen $SCRATCH_MNT 1048576
> > +
> > +# Create our file with a size of 0 and a prealloc extent in the range [0, 2M].
> > +$XFS_IO_PROG -f -c "falloc -k 0 2M" $SCRATCH_MNT/foo
> > +
> > +# Unmount and mount again to remove any in memory state of the inode. We will
> > +# verify later that neither metadata nor extents were lost during unmount.
> > +_scratch_cycle_mount
> > +
> > +# Write into the [0, 1M] range, which increases the inode's i_size.
> > +$XFS_IO_PROG -c "pwrite -S 0xab -b 1M 0 1M" $SCRATCH_MNT/foo | _filter_xfs_io
> > +
> > +# Unmount and mount again to remove any in memory state of the inode. We will
> > +# verify later that neither metadata nor extents were lost during unmount.
> > +_scratch_cycle_mount
> > +
> > +# Check file data (and size).
> > +echo "File data:"
> > +_hexdump $SCRATCH_MNT/foo
> > +
> > +# Check we have unwritten extents in range [1M, 2M].
> > +echo "Fiemap output:"
> > +$XFS_IO_PROG -c "fiemap -v" $SCRATCH_MNT/foo | _filter_fiemap
> > +
> > +# Success, all done.
> > +_exit 0
> > diff --git a/tests/generic/796.out b/tests/generic/796.out
> > new file mode 100644
> > index 00000000..c6c6e6a8
> > --- /dev/null
> > +++ b/tests/generic/796.out
> > @@ -0,0 +1,10 @@
> > +QA output created by 796
> > +wrote 1048576/1048576 bytes at offset 0
> > +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > +File data:
> > +000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab >................<
> > +*
> > +100000
> > +Fiemap output:
> > +0: [0..2047]: data
> > +1: [2048..4095]: unwritten
> > --
> > 2.47.2
> >
> >
prev parent reply other threads:[~2026-06-14 15:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 10:27 [PATCH] generic: add a test case for writes with prealloc extents beyond i_size fdmanana
2026-05-28 11:23 ` Qu Wenruo
2026-05-28 11:30 ` Filipe Manana
2026-05-28 23:52 ` Anand Jain
2026-05-29 1:26 ` Qu Wenruo
2026-06-14 10:57 ` Filipe Manana
2026-06-14 15:24 ` Zorro Lang [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=ai7Fm0OzuKXV1zHw@zlang-mailbox \
--to=zlang@kernel.org \
--cc=fdmanana@kernel.org \
--cc=fdmanana@suse.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.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