Hi,

I have presented 3Par/EVA Luns into RHEL 6.3 and partitioned(one partition) the disk. Then tried sg_inq command on whole disk as well as partition disk. The command failed for partition disk.

I tried same thing ON RHEL 6.1 and RHEL 6.2. The command worked fine for both whole disk and partition disk.


# sg_inq /dev/sdb
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x06 [SPC-4]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=1 Protect=0 BQue=0
EncServ=0 MultiP=1 (VS=0) [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=168 (0xa8) Peripheral device type: disk
Vendor identification: 3PARdata
Product identification: VV
Product revision level: 3122
Unit serial number: 1306584


# sg_inq /dev/sdb1
Both SCSI INQUIRY and fetching ATA information failed on /dev/sdb1[/B]

I can see there is a change in sg3_utils.

On RHEL 6.1
============
# rpm -qa | grep sg3
sg3_utils-libs-1.28-3.el6.x86_64
sg3_utils-1.28-3.el6.x86_64

On RHEL 6.3
===========
# rpm -qa | grep sg3
sg3_utils-libs-1.28-4.el6.x86_64
sg3_utils-1.28-4.el6.x86_64


Can anyone help me to find out what is the changed happen from RHEL 6.2 to RHEL6.3. What is the work around to work this for RHEL 6.3?

Regards,
Phani

Sending disk commands to anything other than a disk is undefined, isn't it?

1 members found this post helpful.

I can confirm from testing on my systems just now that on pre RHEL6.3 running sg_inq on both the disk and a partition of the disk was giving output. However it is the SAME output in both cases (that is you don't get any more from the partition than you did from the disk itself).

Starting with RHEL6.3 running the newer version of sg3_utils (1.28-4) I can also confirm it is NOT giving the output on the partition but is on the disk itself. Also there is a newer version of sg3_utils (1.28-5) in the repositories and updating to that, one still sees it no longer gives the output on the partition.

As the prior poster suggests it probably was never correct for sg_inq to give output on the partition since it is querying the disk's parameters and never giving specifics for the partition anyway. It may be that RedHat "fixed" this silently as I I couldn't find where this got changed but clearly it did get changed.

It likely wasn't RH that made the change, but the upstream project because the package "sg3_utils" runs on more than just Linux (FreeBSD, Solaris, Tru64 and Windows 2000 and later).

Hi, I've experienced the same problem on Linux 6.3-6.5. Have anyone opened a bug to RedHat?

It is NOT a bug but is a change. The tool is to query "disks" not "partitions". As noted above it probably never should have allowed partitions as input and it appears that got silently changed. The output it gave for the "partition" was exactly the same as it gave for the entire "disk" so there is no reason to run it on "partitions" in the first place.

I don't claim that it's problem of tool, but a direct SCSI command built by a program fails as well. INQUIRY command must be supported by disk paths and partitions in order to identify that they relate to the same LUN.

What relates them is the major/minor.

e.g.
For the full disk:
brw-r----- 1 root disk 8, 0 Oct 21 12:02 /dev/sda < Major 8, Minor 0 = first disk

For the partitions:
brw-r----- 1 root disk 8, 1 Oct 21 16:03 /dev/sda1 < Same major, incremented minor 1 = first partition on first disk
brw-r----- 1 root disk 8, 2 Oct 21 12:02 /dev/sda2 < Same major, re-incremented minor 2 = second partition on first disk.

If you have a tool such as Oracle ASM that is renaming things they'll still have the same major/minor as they would before renaming.

You can also get details about paritions with fdisk or parted or by examining things in /sys/class/scsi_host.

The command this thread was started for is specifically to do get sg scsi information on whole disks - not to relate partitions to them.