public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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