All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Max Reitz <mreitz@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic: fallocate two bytes at block boundary
Date: Thu, 26 Sep 2019 09:06:13 -0700	[thread overview]
Message-ID: <20190926160613.GF9913@magnolia> (raw)
In-Reply-To: <c8cf492f-e3e0-e96f-f8f9-49b42b546cf0@redhat.com>

On Thu, Sep 26, 2019 at 06:02:17PM +0200, Max Reitz wrote:
> On 26.09.19 17:55, Darrick J. Wong wrote:
> > On Thu, Sep 26, 2019 at 05:29:27PM +0200, Max Reitz wrote:
> >> Allocating two bytes at a block boundary with fallocate should allocate
> >> both blocks involved.  Test this by writing both bytes with dd
> >> afterwards and see whether the on-disk size increases (it should not).
> >>
> >> Signed-off-by: Max Reitz <mreitz@redhat.com>
> >> ---
> >>  tests/generic/568     | 63 +++++++++++++++++++++++++++++++++++++++++++
> >>  tests/generic/568.out |  2 ++
> >>  tests/generic/group   |  1 +
> >>  3 files changed, 66 insertions(+)
> >>  create mode 100755 tests/generic/568
> >>  create mode 100644 tests/generic/568.out
> >>
> >> diff --git a/tests/generic/568 b/tests/generic/568
> >> new file mode 100755
> >> index 00000000..8fbdcda0
> >> --- /dev/null
> >> +++ b/tests/generic/568
> >> @@ -0,0 +1,63 @@
> >> +#! /bin/bash
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +# Copyright (c) 2019 Red Hat, Inc.  All Rights Reserved.
> >> +#
> >> +# FS QA Test No. generic/568
> >> +#
> >> +# Test that fallocating an unaligned range allocates all blocks
> >> +# touched by that range
> >> +#
> >> +seq=$(basename $0)
> >> +seqres="$RESULT_DIR/$seq"
> >> +echo "QA output created by $seq"
> >> +
> >> +here=$PWD
> >> +tmp=/tmp/$$
> >> +status=1	# failure is the default!
> >> +trap "_cleanup; exit \$status" 0 1 2 3 15
> >> +
> >> +_cleanup()
> >> +{
> >> +	cd /
> >> +	rm -f "$tmp".*
> >> +}
> >> +
> >> +# get standard environment, filters and checks
> >> +. ./common/rc
> >> +. ./common/filter
> >> +
> >> +# real QA test starts here
> >> +_supported_fs generic
> >> +_supported_os Linux
> >> +_require_scratch
> >> +
> >> +testfile="$SCRATCH_MNT/testfile"
> >> +
> >> +_scratch_mkfs > /dev/null 2>&1
> >> +_scratch_mount
> >> +
> >> +# Fallocate 2 bytes across a block boundary
> >> +block_size=$(stat -fc '%S' "$SCRATCH_MNT")
> > 
> > block_size=$(_get_file_block_size $SCRATCH_MNT)
> 
> Ah, nice.
> 
> >> +fallocate -o $((block_size - 1)) -l 2 "$testfile"
> > 
> > If you're going to use an external program, you need to gate the test on
> > whether or not the program's installed, by calling _require_command.
> 
> OK.
> 
> > Though probably the easier way would be to use xfs_io since fstests
> > requires that xfsprogs be installed:
> > 
> > 	$XFS_IO_PROG -f -c "falloc $((block_size - 1)) 2" $testfile
> > 
> > Though you do still have to put at the top of the test:
> > 
> > 	_require_xfs_io_command "falloc"
> > 
> > Because not all filesystems support fallocate.
> 
> So I suppose as long as one doesn’t use special XFS commands, xfs_io is
> filesystem-agnostic?

Right.  At this point xfs_io is largely a testing vehicle for fstests
scripts to call various system calls or ioctls, some of which aren't
even supported on XFS itself. :P

--D

> >> +
> >> +# Both the first blocks should be allocated now.  Check that by
> >> +# inquiring whether the file grows when we write to the two bytes we
> >> +# have just fallocated.
> >> +
> >> +allocated_size_before=$(($(stat -c '%b * %B' "$testfile")))
> >> +
> >> +dd if=/dev/zero of="$testfile" bs=1 conv=notrunc \
> >> +    seek=$((block_size - 1)) count=2 \
> >> +    2>&1 | _filter_dd
> > 
> > $XFS_IO_PROG -c "pwrite $((block_size - 1)) 2" $testfile
> > 
> >> +
> >> +allocated_size_after=$(($(stat -c '%b * %B' "$testfile")))
> >> +
> >> +if [ $allocated_size_after -gt $allocated_size_before ]; then
> >> +	echo "ERROR: File grew from ${allocated_size_before} B to" \
> >> +	     "${allocated_size_after} when writing to the fallocated range."
> >> +else
> >> +	echo "OK: File did not grow."
> > 
> > Other than that, the logic makes sense to me.  Thanks for writing this
> > up!
> 
> OK, thanks, I’ll prepare a v2.
> 
> Max
> 

      reply	other threads:[~2019-09-26 16:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 15:29 [PATCH] generic: fallocate two bytes at block boundary Max Reitz
2019-09-26 15:55 ` Darrick J. Wong
2019-09-26 16:02   ` Max Reitz
2019-09-26 16:06     ` Darrick J. Wong [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=20190926160613.GF9913@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=mreitz@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.