]> git.apps.os.sepia.ceph.com Git - xfstests-dev.git/commit
xfs/128: try to force file allocation behavior
authorDarrick J. Wong <djwong@kernel.org>
Wed, 5 Oct 2022 22:30:55 +0000 (15:30 -0700)
committerZorro Lang <zlang@kernel.org>
Sun, 9 Oct 2022 02:20:55 +0000 (10:20 +0800)
commita2d5043aca5948e98a8d44e2c4e8295befa189a8
treec33f76df569013feadb43448a5ffa7a8654e39d1
parent62d628f7bb7152875f6e748feb11ac27f753d97f
xfs/128: try to force file allocation behavior

Over the years, I've noticed that this test occasionally fails when I've
programmed the allocator to hand out the minimum amount of space with
each allocation or if extent size hints are enabled:

  --- /tmp/fstests/tests/xfs/128.out      2022-09-01 15:09:11.506679341 -0700
  +++ /var/tmp/fstests/xfs/128.out.bad    2022-10-04 17:32:50.992000000 -0700
  @@ -20,7 +21,9 @@
   56ed2f712c91e035adeeb26ed105a982  SCRATCH_MNT/test-128/file3
   b81534f439aac5c34ce3ed60a03eba70  SCRATCH_MNT/test-128/file4
   Check files
   free blocks after creating some reflink copies is in range
   free blocks after CoW some reflink copies is in range
  -free blocks after defragging all reflink copies is in range
  -free blocks after all tests is in range
  +free blocks after defragging all reflink copies has value of 8620027
  +free blocks after defragging all reflink copies is NOT in range 8651819 .. 8652139
  +free blocks after all tests has value of 8620027
  +free blocks after all tests is NOT in range 8651867 .. 8652187

It turns out that under the right circumstances, the _pwrite_byte at the
start of this test will end up allocating two extents to file1.  This
almost never happens when delalloc is enabled or when the extent size is
large, and is more prone to happening if the extent size is > 1FSB but
small, the allocator hands out small allocations, or if writeback shoots
down pages in random order.

When file1 gets more than 1 extent, problems start to happen.  The free
space accounting checks at the end of the test assume that file1 and
file4 still share the same space at the end of the test.  This
definitely happens if file1 gets one extent (since fsr ignores
single-extent files), but if there's more than 1, fsr will try to
defragment it.  If fsr succeeds in copying the file contents to a temp
file with fewer extents than the source file, it will switch the
contents, but unsharing the contents in the process.  This cause the
free space to be lower than expected, and the test fails.

Resolve this situation by preallocating space beforehand to try to set
up file1 with a single space extent.  If the test fails and we got more
than one extent, note that in the output.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
tests/xfs/128