From: Nitesh Shetty <nj.shetty@samsung.com>
To: "Darrick J. Wong" <djwong@kernel.org>
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 17:37:18 +0530 [thread overview]
Message-ID: <20220323120718.GC19899@test-zns> (raw)
In-Reply-To: <20220322160756.GM8200@magnolia>
[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]
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`
--Nitesh Shetty
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2022-03-23 13:25 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 [this message]
2022-03-23 16:53 ` Darrick J. Wong
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=20220323120718.GC19899@test-zns \
--to=nj.shetty@samsung.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=nitheshshetty@gmail.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