From: "Darrick J. Wong" <djwong@kernel.org>
To: Nitesh Shetty <nj.shetty@samsung.com>
Cc: fstests@vger.kernel.org, nitheshshetty@gmail.com,
p.raghav@samsung.com, joshi.k@samsung.com,
arnav.dawn@samsung.com, mcgrof@kernel.org
Subject: Re: [PATCH] xfs/205,432,516: read sysfs for mkfs block size instead of hardcoded values
Date: Wed, 2 Mar 2022 14:57:00 -0800 [thread overview]
Message-ID: <20220302225700.GA117704@magnolia> (raw)
In-Reply-To: <20220301213022.28999-1-nj.shetty@samsung.com>
On Wed, Mar 02, 2022 at 03:00:22AM +0530, Nitesh Shetty wrote:
> At present block size of 1024 is hardcoded for mkfs. This creates
> problem when device block size is more than 1024. So we use sysfs values
What kinds of problems?
> of SCRATCH_DEV, if not found then default to 1024.
>
> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
> ---
> tests/xfs/205 | 3 ++-
> tests/xfs/432 | 3 ++-
> tests/xfs/516 | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/xfs/205 b/tests/xfs/205
> index 104f1f45..73e32c4d 100755
> --- a/tests/xfs/205
> +++ b/tests/xfs/205
> @@ -22,7 +22,8 @@ _require_scratch_nocheck
> # bitmap consuming all the free space in our small data device.
> unset SCRATCH_RTDEV
>
> -fsblksz=1024
> +physical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/physical_block_size)
For a disk with 512 byte sectors, does this set physical=512?
The code within the $() really ought to be turned into a helper
_scratch_dev_phys_block_size or something.
> +fsblksz=${physical:-1024}
Filesystem blocksize isn't supposed to be smaller than the physical
blocksize, but why do you change the fs block size to the physical size?
> _scratch_mkfs_xfs -d size=$((32768*fsblksz)) -b size=$fsblksz >> $seqres.full 2>&1
> _scratch_mount
>
> diff --git a/tests/xfs/432 b/tests/xfs/432
> index 86012f0b..cd6367e2 100755
> --- a/tests/xfs/432
> +++ b/tests/xfs/432
> @@ -49,7 +49,8 @@ echo "Format and mount"
> # block. 8187 hashes/dablk / 248 dirents/dirblock = ~33 dirblocks per
> # dablock. 33 dirblocks * 64k mean that we can expand a directory by
> # 2112k before we have to allocate another da btree block.
> -_scratch_mkfs -b size=1k -n size=64k > "$seqres.full" 2>&1
> +physical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/physical_block_size)
> +_scratch_mkfs -b size=${physical:-1k} -n size=64k > "$seqres.full" 2>&1
This test formats a very specific geometry because it needs precise
calculations to generate a directory with 1000 consecutively mapped
blocks. Does it still do that if the blocksize isn't 1k?
> _scratch_mount >> "$seqres.full" 2>&1
>
> metadump_file="$TEST_DIR/meta-$seq"
> diff --git a/tests/xfs/516 b/tests/xfs/516
> index 9e1b9931..b9d4f0c9 100755
> --- a/tests/xfs/516
> +++ b/tests/xfs/516
> @@ -84,7 +84,8 @@ test_su_opts()
> local mounted=0
>
> echo "Format with 256k stripe unit; 4x stripe width" >> $seqres.full
> - _scratch_mkfs -b size=1k -d su=256k,sw=4 >> $seqres.full 2>&1
> + physical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/physical_block_size)
> + _scratch_mkfs -b size=${physical:-1k} -d su=256k,sw=4 >> $seqres.full 2>&1
This is a test of sunit/swidth. Do you need to scale those up as well?
--D
>
> __test_mount_opts "$@"
> }
>
> base-commit: 2ea74ba4e70b546279896e2a733c8c7f4b206193
> --
> 2.25.1
>
next prev parent reply other threads:[~2022-03-03 0:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220301213529epcas5p2974c84878339d5661336533696d3938f@epcas5p2.samsung.com>
2022-03-01 21:30 ` [PATCH] xfs/205,432,516: read sysfs for mkfs block size instead of hardcoded values Nitesh Shetty
2022-03-02 20:36 ` Luis Chamberlain
2022-03-02 22:57 ` Darrick J. Wong [this message]
2022-03-04 20:48 ` Nitesh Shetty
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=20220302225700.GA117704@magnolia \
--to=djwong@kernel.org \
--cc=arnav.dawn@samsung.com \
--cc=fstests@vger.kernel.org \
--cc=joshi.k@samsung.com \
--cc=mcgrof@kernel.org \
--cc=nitheshshetty@gmail.com \
--cc=nj.shetty@samsung.com \
--cc=p.raghav@samsung.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