From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org,
josef@toxicpanda.com, david@fromorbit.com
Subject: Re: [PATCH v2 1/4] fsx: don't skip file size and buf updates on simulated ops
Date: Thu, 29 Aug 2024 10:56:49 -0400 [thread overview]
Message-ID: <ZtCMMSaA-yEw73lX@bfoster> (raw)
In-Reply-To: <20240829012716.GF6224@frogsfrogsfrogs>
On Wed, Aug 28, 2024 at 06:27:16PM -0700, Darrick J. Wong wrote:
> On Wed, Aug 28, 2024 at 02:15:31PM -0400, Brian Foster wrote:
> > fsx supports the ability to skip through a certain number of
> > operations of a given command sequence before beginning full
> > operation. The way this works is by tracking the operation count,
> > simulating minimal side effects of skipped operations in-memory, and
> > then finally writing out the in-memory state to the target file when
> > full operation begins.
> >
> > Several fallocate() related operations don't correctly track
> > in-memory state when simulated, however. For example, consider an
> > ops file with the following two operations:
> >
> > zero_range 0x0 0x1000 0x0
> > read 0x0 0x1000 0x0
> >
> > ... and an fsx run like so:
> >
> > fsx -d -b 2 --replay-ops=<opsfile> <file>
> >
> > This simulates the zero_range operation, but fails to track the file
> > extension that occurs as a side effect such that the subsequent read
> > doesn't occur as expected:
> >
> > Will begin at operation 2
> > skipping zero size read
> >
> > The read is skipped in this case because the file size is zero. The
> > proper behavior, and what is consistent with other size changing
> > operations, is to make the appropriate in-core changes before
> > checking whether an operation is simulated so the end result of
> > those changes can be reflected on-disk for eventual non-simulated
> > operations. This results in expected behavior with the same ops file
> > and test command:
> >
> > Will begin at operation 2
> > 2 read 0x0 thru 0xfff (0x1000 bytes)
> >
> > Update zero, copy and clone range to do the file size and EOF change
> > related zeroing before checking against the simulated ops count.
> >
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
>
> Oh wow, I really got that wrong. :(
>
Eh, so did I. ;) That the code was mostly right was pretty much just
luck. Thanks for the thoughtful reviews.
Brian
> Well, thank you for uncovering that error;
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
>
> --D
>
>
> > ---
> > ltp/fsx.c | 40 +++++++++++++++++++++-------------------
> > 1 file changed, 21 insertions(+), 19 deletions(-)
> >
> > diff --git a/ltp/fsx.c b/ltp/fsx.c
> > index 2dc59b06..c5727cff 100644
> > --- a/ltp/fsx.c
> > +++ b/ltp/fsx.c
> > @@ -1247,6 +1247,17 @@ do_zero_range(unsigned offset, unsigned length, int keep_size)
> > log4(OP_ZERO_RANGE, offset, length,
> > keep_size ? FL_KEEP_SIZE : FL_NONE);
> >
> > + if (!keep_size && end_offset > file_size) {
> > + /*
> > + * If there's a gap between the old file size and the offset of
> > + * the zero range operation, fill the gap with zeroes.
> > + */
> > + if (offset > file_size)
> > + memset(good_buf + file_size, '\0', offset - file_size);
> > +
> > + file_size = end_offset;
> > + }
> > +
> > if (testcalls <= simulatedopcount)
> > return;
> >
> > @@ -1263,17 +1274,6 @@ do_zero_range(unsigned offset, unsigned length, int keep_size)
> > }
> >
> > memset(good_buf + offset, '\0', length);
> > -
> > - if (!keep_size && end_offset > file_size) {
> > - /*
> > - * If there's a gap between the old file size and the offset of
> > - * the zero range operation, fill the gap with zeroes.
> > - */
> > - if (offset > file_size)
> > - memset(good_buf + file_size, '\0', offset - file_size);
> > -
> > - file_size = end_offset;
> > - }
> > }
> >
> > #else
> > @@ -1538,6 +1538,11 @@ do_clone_range(unsigned offset, unsigned length, unsigned dest)
> >
> > log5(OP_CLONE_RANGE, offset, length, dest, FL_NONE);
> >
> > + if (dest > file_size)
> > + memset(good_buf + file_size, '\0', dest - file_size);
> > + if (dest + length > file_size)
> > + file_size = dest + length;
> > +
> > if (testcalls <= simulatedopcount)
> > return;
> >
> > @@ -1556,10 +1561,6 @@ do_clone_range(unsigned offset, unsigned length, unsigned dest)
> > }
> >
> > memcpy(good_buf + dest, good_buf + offset, length);
> > - if (dest > file_size)
> > - memset(good_buf + file_size, '\0', dest - file_size);
> > - if (dest + length > file_size)
> > - file_size = dest + length;
> > }
> >
> > #else
> > @@ -1756,6 +1757,11 @@ do_copy_range(unsigned offset, unsigned length, unsigned dest)
> >
> > log5(OP_COPY_RANGE, offset, length, dest, FL_NONE);
> >
> > + if (dest > file_size)
> > + memset(good_buf + file_size, '\0', dest - file_size);
> > + if (dest + length > file_size)
> > + file_size = dest + length;
> > +
> > if (testcalls <= simulatedopcount)
> > return;
> >
> > @@ -1792,10 +1798,6 @@ do_copy_range(unsigned offset, unsigned length, unsigned dest)
> > }
> >
> > memcpy(good_buf + dest, good_buf + offset, length);
> > - if (dest > file_size)
> > - memset(good_buf + file_size, '\0', dest - file_size);
> > - if (dest + length > file_size)
> > - file_size = dest + length;
> > }
> >
> > #else
> > --
> > 2.45.0
> >
> >
>
next prev parent reply other threads:[~2024-08-29 14:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 18:15 [PATCH v2 0/4] fstests/fsx: test coverage for eof zeroing Brian Foster
2024-08-28 18:15 ` [PATCH v2 1/4] fsx: don't skip file size and buf updates on simulated ops Brian Foster
2024-08-29 1:27 ` Darrick J. Wong
2024-08-29 14:56 ` Brian Foster [this message]
2024-08-28 18:15 ` [PATCH v2 2/4] fsx: factor out a file size update helper Brian Foster
2024-08-29 1:28 ` Darrick J. Wong
2024-08-28 18:15 ` [PATCH v2 3/4] fsx: support eof page pollution for eof zeroing test coverage Brian Foster
2024-08-29 1:35 ` Darrick J. Wong
2024-08-28 18:15 ` [PATCH v2 4/4] generic: test to run fsx eof pollution Brian Foster
2024-08-29 1:37 ` Darrick J. Wong
2024-09-02 20:11 ` [PATCH v2 0/4] fstests/fsx: test coverage for eof zeroing Zorro Lang
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=ZtCMMSaA-yEw73lX@bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-xfs@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