From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz,
Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: fix device lookup in btrfs/003
Date: Fri, 06 Sep 2013 10:41:04 -0400 [thread overview]
Message-ID: <5229E980.3000904@suse.com> (raw)
In-Reply-To: <20130906140337.GK32382@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
On 9/6/13 10:03 AM, David Sterba wrote:
> On Tue, Sep 03, 2013 at 06:19:01PM -0400, Jeff Mahoney wrote:
>> The DEVHTL lookup in btrfs/003 is broken. It can only handle full LUNs and
>> not partitions on a disk.
>>
>> Rather than returning 2:0:0:0 for /dev/sdc7, it returns 'block' and we see:
>> ./common/rc: line 2081: /sys/class/scsi_device/block/device/delete:
>> No such file or directory
>>
>> If we look up the device by dev instead of by name, we can handle working
>> with full disks and partitions more easily and get the ability to use
>> any device name rather than just the ones that match sysfs.
>>
>> @@ -137,9 +137,21 @@ _test_replace()
>> #pick the 2nd last disk
>> ds=${devs[@]:$(($n-1)):1}
>>
>> - # retrive the HTL for this scsi disk
>> - d=`echo $ds|cut -d"/" -f3`
>> - DEVHTL=`ls -l /sys/class/block/${d} | rev | cut -d "/" -f 3 | rev`
>> + HEXMAJOR="$(stat -c "%t" "$ds")"
>> + HEXMINOR="$(stat -c "%T" "$ds")"
>> + if [ -z "$HEXMAJOR" -o -z "$HEXMINOR" ]; then
>> + _fail "tr: HEXMAJOR and/or HEXMINOR is unset for $ds"
>> + fi
>> +
>> + DIR="/sys/dev/block/$(( 0x$HEXMAJOR )):$(( 0x$HEXMINOR ))"
>> +
>> + if [ -L "$DIR/device" ]; then # whole disk
>> + DEVHTL="$(basename $(readlink "$DIR/device"))"
>> + elif [ -L "$DIR/../device" ]; then # partition
>> + DEVHTL="$(basename $(readlink "$DIR/../device"))"
>> + else
>> + _fail "tr: Can't locate device backing $ds"
>> + fi
>>
>> #fail disk
>> _devmgt_remove ${DEVHTL}
>
> The test assumes tha SCRATCH_DEV_POOL consists of standalone devices
> and more strongly that they can be removed from the system by
>
> $ echo 1 > /sys/class/scsi_device/sdx/device/delete
>
> via _devmgt_remove. Ordinary sdX devices are ok, but eg. MD devices are
> not because they do not have a corresponding "2:0:0:0"-like entry (I
> haven't checked device-mapper devices).
>
> Looks like the tests have to do more fine grained checks of the devices
> in SCRATCH_DEV_POOL because eg. the 'device replace' test btrfs/011 is
> just fine with partitions.
Yeah. It doesn't work with any type of device that doesn't present a
SCSI-style host interface with a delete sysfs entry. I wasn't looking to
make it work everywhere, just allow it to work with the types of devices
it was originally targeting in a slightly less fragile way.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz,
Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: fix device lookup in btrfs/003
Date: Fri, 06 Sep 2013 10:41:04 -0400 [thread overview]
Message-ID: <5229E980.3000904@suse.com> (raw)
In-Reply-To: <20130906140337.GK32382@twin.jikos.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2400 bytes --]
On 9/6/13 10:03 AM, David Sterba wrote:
> On Tue, Sep 03, 2013 at 06:19:01PM -0400, Jeff Mahoney wrote:
>> The DEVHTL lookup in btrfs/003 is broken. It can only handle full LUNs and
>> not partitions on a disk.
>>
>> Rather than returning 2:0:0:0 for /dev/sdc7, it returns 'block' and we see:
>> ./common/rc: line 2081: /sys/class/scsi_device/block/device/delete:
>> No such file or directory
>>
>> If we look up the device by dev instead of by name, we can handle working
>> with full disks and partitions more easily and get the ability to use
>> any device name rather than just the ones that match sysfs.
>>
>> @@ -137,9 +137,21 @@ _test_replace()
>> #pick the 2nd last disk
>> ds=${devs[@]:$(($n-1)):1}
>>
>> - # retrive the HTL for this scsi disk
>> - d=`echo $ds|cut -d"/" -f3`
>> - DEVHTL=`ls -l /sys/class/block/${d} | rev | cut -d "/" -f 3 | rev`
>> + HEXMAJOR="$(stat -c "%t" "$ds")"
>> + HEXMINOR="$(stat -c "%T" "$ds")"
>> + if [ -z "$HEXMAJOR" -o -z "$HEXMINOR" ]; then
>> + _fail "tr: HEXMAJOR and/or HEXMINOR is unset for $ds"
>> + fi
>> +
>> + DIR="/sys/dev/block/$(( 0x$HEXMAJOR )):$(( 0x$HEXMINOR ))"
>> +
>> + if [ -L "$DIR/device" ]; then # whole disk
>> + DEVHTL="$(basename $(readlink "$DIR/device"))"
>> + elif [ -L "$DIR/../device" ]; then # partition
>> + DEVHTL="$(basename $(readlink "$DIR/../device"))"
>> + else
>> + _fail "tr: Can't locate device backing $ds"
>> + fi
>>
>> #fail disk
>> _devmgt_remove ${DEVHTL}
>
> The test assumes tha SCRATCH_DEV_POOL consists of standalone devices
> and more strongly that they can be removed from the system by
>
> $ echo 1 > /sys/class/scsi_device/sdx/device/delete
>
> via _devmgt_remove. Ordinary sdX devices are ok, but eg. MD devices are
> not because they do not have a corresponding "2:0:0:0"-like entry (I
> haven't checked device-mapper devices).
>
> Looks like the tests have to do more fine grained checks of the devices
> in SCRATCH_DEV_POOL because eg. the 'device replace' test btrfs/011 is
> just fine with partitions.
Yeah. It doesn't work with any type of device that doesn't present a
SCSI-style host interface with a delete sysfs entry. I wasn't looking to
make it work everywhere, just allow it to work with the types of devices
it was originally targeting in a slightly less fragile way.
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-06 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 22:19 [PATCH] xfstests: fix device lookup in btrfs/003 Jeff Mahoney
2013-09-04 23:24 ` Dave Chinner
2013-09-04 23:24 ` Dave Chinner
2013-09-06 14:03 ` David Sterba
2013-09-06 14:03 ` David Sterba
2013-09-06 14:41 ` Jeff Mahoney [this message]
2013-09-06 14:41 ` Jeff Mahoney
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=5229E980.3000904@suse.com \
--to=jeffm@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.