FS/XFS testing framework
 help / color / mirror / Atom feed
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 --]



  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