All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: zlang@redhat.com, djwong@kernel.org
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 5/7] fiemap-tester: holes can be backed by unwritten extents
Date: Tue, 02 May 2023 13:08:34 -0700	[thread overview]
Message-ID: <168305811472.331137.10386168929752413533.stgit@frogsfrogsfrogs> (raw)
In-Reply-To: <168305808594.331137.16455277063177572891.stgit@frogsfrogsfrogs>

From: Darrick J. Wong <djwong@kernel.org>

Filesystem behavior is pretty open-ended for sparse ranges (i.e. holes)
of a file that have not yet been written to.  That space can remain
unmapped, it can be mapped to written space that has been zeroed, or it
can be mapped to unwritten extents.

This program trips over that last condition on XFS.  If the file is
located on a data device with a raid stripe geometry or on a realtime
device with a realtime extent size larger than 1 filesystem block, it's
possible for unwritten areas to be backed by unwritten preallocations or
unwritten rt blocks, respectively.

Fix the test to skip unwritten extents here.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 src/fiemap-tester.c |    7 +++++++
 1 file changed, 7 insertions(+)


diff --git a/src/fiemap-tester.c b/src/fiemap-tester.c
index 3db24daa79..7e9f9fe8c1 100644
--- a/src/fiemap-tester.c
+++ b/src/fiemap-tester.c
@@ -375,6 +375,13 @@ check_hole(struct fiemap *fiemap, int fd, __u64 logical_offset, int blocksize)
 		if (logical_offset + blocksize < start)
 			break;
 
+		/*
+		 * Filesystems are allowed to fill in holes with preallocated
+		 * unwritten extents
+		 */
+		if (extent->fe_flags & FIEMAP_EXTENT_UNWRITTEN)
+			continue;
+
 		if (logical_offset >= start &&
 		    logical_offset < end) {
 


  parent reply	other threads:[~2023-05-02 20:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 20:08 [PATCHSET 0/7] fstests: random fixes for v2023.05.01 Darrick J. Wong
2023-05-02 20:08 ` [PATCH 1/7] fsx: fix indenting of columns in bad buffers report Darrick J. Wong
2023-05-02 20:08 ` [PATCH 2/7] xfs/262: remove dangerous labels Darrick J. Wong
2023-05-02 20:08 ` [PATCH 3/7] generic/724,xfs/791: adjust test preconditions for post-EOF stripe zeroing Darrick J. Wong
2023-05-02 20:08 ` [PATCH 4/7] xfs/{243,245,272,274}: ignore raid alignment flags in bmap output Darrick J. Wong
2023-05-02 20:08 ` Darrick J. Wong [this message]
2023-05-02 20:08 ` [PATCH 6/7] fiemap: FIEMAP_EXTENT_LAST denotes the last record in the recordset Darrick J. Wong
2023-05-02 20:08 ` [PATCH 7/7] generic/{094,225}: drop the file allocation unit requirements 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=168305811472.331137.10386168929752413533.stgit@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.