linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anajain.sg@gmail.com>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] common/rc: helper functions to handle block devices via sysfs
Date: Tue, 30 Sep 2025 11:47:38 +0800	[thread overview]
Message-ID: <CANZP331iHxPpL0kQfwhzQrSkevs9KS8NF9cvcc-KNDUexM7wbQ@mail.gmail.com> (raw)
In-Reply-To: <20250926155753.yhhrbfnilvmk2t47@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>

On 26/9/25 23:57, Zorro Lang wrote:
> On Thu, Sep 18, 2025 at 08:32:46AM +0800, Anand Jain wrote:
>> From: Anand Jain <anand.jain@oracle.com>
>>
>> _bdev_handle(dev)
>>      get sysfs handle for a given block device.
>>
>> _has_bdev_sysfs_delete(dev_path)
>>      Checks if the block device supports sysfs-based delete.
>>
>> _require_scratch_bdev_delete()
>>      Test if the scratch device does not support sysfs delete.
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>>   common/rc | 26 ++++++++++++++++++++++++++
>>   1 file changed, 26 insertions(+)
>>
>> diff --git a/common/rc b/common/rc
>> index 81587dad500c..627ddcc02fb8 100644
>> --- a/common/rc
>> +++ b/common/rc
>> @@ -4388,6 +4388,32 @@ _get_file_extent_sector()
>>      echo "$result"
>>   }
>>
>> +_bdev_handle()
>> +{
>> +    local device=$(echo $1 | rev | cut -d"/" -f1 | rev)
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> basename $1 ?
>
> if you hope to make sure it's not link, you can
>

> basename $(_real_dev $1)

Whoops, not sure what I was thinking. There's actually a helper for
this, _short_dev().
The changes below will fix it. I can send v2 if needed, unless it can
be fixed at merge
time. Let me know what works best.
-----------------------------------
$ git diff
diff --git a/common/rc b/common/rc
index 627ddcc02fb8..085fab6e34f0 100644
--- a/common/rc
+++ b/common/rc
@@ -4390,7 +4390,7 @@ _get_file_extent_sector()

 _bdev_handle()
 {
-       local device=$(echo $1 | rev | cut -d"/" -f1 | rev)
+       local device=$(_short_dev $1)

        test -e /sys/class/block/${device}/device/scsi_disk/ || \
                        _notrun "Failed to obtain sys block handle"
@@ -4401,7 +4401,7 @@ _bdev_handle()
 _has_bdev_sysfs_delete()
 {
        local dev_path=$1
-       local device=$(echo $dev_path | rev | cut -d"/" -f1 | rev)
+       local device=$(_short_dev $1)
        local delete_path=/sys/class/block/${device}/device/delete

        test -e $delete_path
---------------------------------------------


>> +
>> +    test -e /sys/class/block/${device}/device/scsi_disk/ || \
>> +                    _notrun "Failed to obtain sys block handle"
>> +
>> +    ls /sys/class/block/${device}/device/scsi_disk/
>> +}
>> +
>> +_has_bdev_sysfs_delete()
>> +{
>> +    local dev_path=$1
>> +    local device=$(echo $dev_path | rev | cut -d"/" -f1 | rev)
>> +    local delete_path=/sys/class/block/${device}/device/delete
>> +
>> +    test -e $delete_path
>> +}
>> +
>> +_require_scratch_bdev_delete()
>> +{
>
> I'm wondering if it's better to call "_require_block_device" at first, before
> checking the /sys ?

There’s no harm in using _require_block_device() here, but I don’t
think it will help,
a non block device won't reach this place anyway.
config: _check_device() will fail for non-block devices.

Thanks, Anand

>> +    if ! _has_bdev_sysfs_delete $SCRATCH_DEV; then
>> +            _notrun "require scratch device sys delete support"
>> +    fi
>> +}
>> +
>>   # arg 1 is dev to remove and is output of the below eg.
>>   # ls -l /sys/class/block/sdd | rev | cut -d "/" -f 3 | rev
>>   _devmgt_remove()
>> --
>> 2.51.0
>>
>>
>

  reply	other threads:[~2025-09-30  3:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18  0:32 [PATCH 0/2] fstests: test device reappearance with new maj:min Anand Jain
2025-09-18  0:32 ` [PATCH 1/2] common/rc: helper functions to handle block devices via sysfs Anand Jain
2025-09-26 15:57   ` Zorro Lang
2025-09-30  3:47     ` Anand Jain [this message]
2025-09-18  0:32 ` [PATCH 2/2] generic: test case for reappearing device Anand Jain
2025-09-18 17:15 ` [PATCH 0/2] fstests: test device reappearance with new maj:min Neal Gompa

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=CANZP331iHxPpL0kQfwhzQrSkevs9KS8NF9cvcc-KNDUexM7wbQ@mail.gmail.com \
    --to=anajain.sg@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zlang@redhat.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;
as well as URLs for NNTP newsgroup(s).