From: "Darrick J. Wong" <djwong@kernel.org>
To: Pavel Reichl <preichl@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic: test i_blocks for truncated large files
Date: Wed, 7 Sep 2022 08:26:55 -0700 [thread overview]
Message-ID: <Yxi4PwiigCspU7qD@magnolia> (raw)
In-Reply-To: <20220906155320.952636-1-preichl@redhat.com>
On Tue, Sep 06, 2022 at 05:53:20PM +0200, Pavel Reichl wrote:
> This is a regression test for an incorrect computation of i_blocks for
> truncated files larger than 4 GiB. Bug was filed for exFAT.
>
> Test is based on reproducer provied by Christophe Vu-Brugier as part
> of kernel patch-fix submission.
>
> Signed-off-by: Pavel Reichl <preichl@redhat.com>
> ---
> tests/generic/698 | 47 +++++++++++++++++++++++++++++++++++++++++++
> tests/generic/698.out | 2 ++
> 2 files changed, 49 insertions(+)
> create mode 100755 tests/generic/698
> create mode 100644 tests/generic/698.out
>
> diff --git a/tests/generic/698 b/tests/generic/698
> new file mode 100755
> index 00000000..217641e6
> --- /dev/null
> +++ b/tests/generic/698
> @@ -0,0 +1,47 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2022 Red Hat Inc. All Rights Reserved.
> +#
> +# FS QA Test 698
> +#
> +# Verify that i_blocks for truncated files larger than 4 GiB have correct
> +# values.
> +#
> +# This test verifies the problem fixed in kernel with commit
> +# 92fba084b79e exfat: fix i_blocks for files truncated over 4 GiB
> +#
> +. ./common/preamble
> +_begin_fstest auto
> +
> +# Override the default cleanup function.
> +_cleanup()
> +{
> + cd /
> + rm -r -f $tmp.* $junk_dir
> +}
> +
> +_supported_fs generic
> +_require_test
> +_require_fs_space $TEST_DIR $((5 * 1024 * 1024)) #kB
> +
> +echo "Silence is golden"
> +
> +junk_dir=$TEST_DIR/$seq
> +junk_file=$junk_dir/junk
> +mkdir -p $junk_dir
> +
> +$XFS_IO_PROG -f -c "pwrite -W 0 5G" $junk_file > /dev/null
> +
> +
> +truncate -s $((4 * 1024 * 1024 * 1024)) $junk_file
> +
> +iblocks_after_truncate=`stat -c '%b' $junk_file`
> +iblocks_expected=$((4 * 1024 * 1024 * 2))
What happens if the filesystem allocates a substantial number of blocks
to store block mappings (e.g. ext2)? Those are accounted to i_blocks.
> +
> +if [ "$iblocks_expected" != "$iblocks_after_truncate" ]; then
> + echo "Number of blocks needs to be same: $iblocks_expected, $iblocks_after_truncate"
_within_range?
--D
> +fi
> +
> +status=0
> +
> +exit
> diff --git a/tests/generic/698.out b/tests/generic/698.out
> new file mode 100644
> index 00000000..222db0de
> --- /dev/null
> +++ b/tests/generic/698.out
> @@ -0,0 +1,2 @@
> +QA output created by 698
> +Silence is golden
> --
> 2.37.3
>
prev parent reply other threads:[~2022-09-07 15:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 15:53 [PATCH] generic: test i_blocks for truncated large files Pavel Reichl
2022-09-07 1:05 ` Zorro Lang
2022-09-07 4:49 ` Zorro Lang
2022-09-07 15:26 ` 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=Yxi4PwiigCspU7qD@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=preichl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox