From: "Darrick J. Wong" <djwong@kernel.org>
To: Nitesh Shetty <nj.shetty@samsung.com>
Cc: fstests@vger.kernel.org, nitheshshetty@gmail.com
Subject: Re: [PATCH] generic/108: use sysfs values for logical,physical block size in scsi_debug
Date: Wed, 23 Mar 2022 09:53:09 -0700 [thread overview]
Message-ID: <20220323165309.GQ8200@magnolia> (raw)
In-Reply-To: <20220323120718.GC19899@test-zns>
On Wed, Mar 23, 2022 at 05:37:18PM +0530, Nitesh Shetty wrote:
> On Tue, Mar 22, 2022 at 09:07:56AM -0700, Darrick J. Wong wrote:
> > On Tue, Mar 22, 2022 at 01:56:29PM +0530, Nitesh Shetty wrote:
> > > Mon, Mar 21, 2022 at 01:21:33PM -0700, Darrick J. Wong wrote:
> > > > On Wed, Mar 02, 2022 at 02:59:47AM +0530, Nitesh Shetty wrote:
> > > > > scsi_debug device used for test, is created with assumption of 512 bytes
> > > > > logical and physical block size.
> > > > > This causes error in lvcreate step, when SCRATCH_DEV device lba is not
> > > > > 512 bytes. This can be solved by reading block size from sysfs of device.
> > > > > If sysfs is missing fallback to 512 bytes as default.
> > > > >
> > > > > Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
> > > > > ---
> > > > > tests/generic/108 | 5 ++++-
> > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tests/generic/108 b/tests/generic/108
> > > > > index ad43269f..db0e9bd0 100755
> > > > > --- a/tests/generic/108
> > > > > +++ b/tests/generic/108
> > > > > @@ -42,8 +42,11 @@ _require_non_zoned_device $SCRATCH_DEV
> > > > > lvname=lv_$seq
> > > > > vgname=vg_$seq
> > > > >
> > > > > +physical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/physical_block_size)
> > > > > +logical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/logical_block_size)
> > > >
> > > > This causes a regression if $SCRATCH_DEV is not a raw block device:
> > > >
> > > Acked, I was testing for NVMe device, missed out sda sysfs.
> > > Let me see, if I can use other sysfs/utility to get block size of device.
> > >
> > > Also I see many 4k LBA tests failing mainly because of setup failure in
> > > format command. This is not actually test failure, rather setup failure.
> > > So what do you suggest for those type of tests?
> >
> > Ideally, fix the ones that can be fixed, and _notrun the rest.
> >
>
> Sure, will send a different patchset.
>
> > > Should I put them in not run status or just report to community so that
> > > person with relevant expertise can add a fix?
> >
> > For this specific problem I suggest creating a function that finds the
> > /sys/block/XXX path for any given block device or partition, and then
> > update all the open coded logic to use it. Something like:
> >
> > # Map a block device to its counterpart in sysfs
> > _sysfs_block() {
> > local dev="$1"
> > local shortdev="$(_short_dev "$dev")"
> >
> > # Full block devices are simple
> > local ret="/sys/block/$shortdev"
> > if [ -e "$ret" ]; then
> > readlink -m "$ret"
> > return 0
> > fi
> >
> > # Partitions are a little trickier
> > ret="/sys/class/block/$shortdev"
> > if [ -e "$ret/partition" ]; then
> > readlink -m "$ret/.."
> > return 0
> > fi
> >
> > # ???
> > return 1
> > }
> >
> > sysfsb=$(_sysfs_block $SCRATCH_DEV)
> > physical=$(cat $sysfsb/queue/physical_block_size)
> >
> > --D
> >
>
> As a alternate, using blockdev utility might reduce and simplify the
> changes required. how about below changes ?
>
> -physical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/physical_block_size)
> -logical=$(cat /sys/block/$(_short_dev $SCRATCH_DEV)/queue/logical_block_size)
> +physical=`blockdev --getpbsz $SCRATCH_DEV`
> +logical=`blockdev --getss $SCRATCH_DEV`
Good idea! :)
--D
> --Nitesh Shetty
prev parent reply other threads:[~2022-03-23 16:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220301213455epcas5p30ff48390a70523f4bc3d99de0027d3bd@epcas5p3.samsung.com>
2022-03-01 21:29 ` [PATCH] generic/108: use sysfs values for logical,physical block size in scsi_debug Nitesh Shetty
2022-03-02 20:36 ` Luis Chamberlain
2022-03-21 20:21 ` Darrick J. Wong
2022-03-22 8:26 ` Nitesh Shetty
2022-03-22 16:07 ` Darrick J. Wong
2022-03-23 12:07 ` Nitesh Shetty
2022-03-23 16:53 ` 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=20220323165309.GQ8200@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=nitheshshetty@gmail.com \
--cc=nj.shetty@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