Red Hat Bugzilla – Bug 178488
endianness issues in mpath_prio_alua
Last modified: 2010-01-11 21:23:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
mpath_prio_alua mishandles endianness in inquiry data, due to a struct definition that does not apply to both big-endian and little-endian architectures.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run mpath_prio_alua on a storage target supporting ALUA on i386 platform
Actual Results: when run with the -v option, mpath_prio_alua claims that
Target port groups are not supported.
when in fact they really are.
Expected Results: the program should go on and do the RTPG and return a proper prio.
the struct definition of inquiry_data in spc3.h should handle both big-endian and little-endian architectures.
I do not have a target that supports ALUA handy, so I can't be sure of this, but
I can't see any problems with the inquiry_data structure.
This is my reasoning. Please reply if I'm misunderstanding something:
You are seeing a message saying "Target port groups are not supported" To get
that, mpath_prio_alua sends a SCSI inquiry command to the target. If the command
failed, this message would not be printed, so if there is a problem, it would
show up in the inquiry_data_get_tpgs() function. According to the SPC-3 spec,
byte 5 of the standard inquiry data format is exactly what b5 of inquiry_data
says it is. inquiry_data_get_tpgs() looks at the fourth and fifth bit in the
byte. Since inquire_data_get_tpgs() is only dealing with a single byte, I cannot
see how there could be an endianness issue. Some computers place the most
significant byte of a multibyte value first (big endian), some computers place
the least significant byte of a multibyte value first (little endian). All
computers see the individual bytes the same way. So inquire_data_get_tpgs will
always see the same data in the fourth and fifth bits of b5, regardless of
whether the machine is big endian or little endian.
I apologize if I'm overlooking some endianness issue. But in case I am not,
what type of storage target are you using?
Have you tried using the sq_inq command from the sg3_utils package on your
On my storage, I get
[root@cypher-05 sg3_utils-1.19]# sg_inq /dev/sda
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=1] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TGPS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: Tornado-
Product identification: F8 V2.0
Product revision level:
Unit serial number: 009408910001032
The "TGPS=0" means that Target port groups are not supported on my storage. If
this command also comes back saying that Target port groups are not supported on
your storage, then they probably aren't. If TGPS is not zero, then there
probably is a bug in mpath_prio_alua
this does work in christophe's git tree HOL mpath_prio_alua.
[root@ca-devapm-73 lib]# ls -l /sbin/mpath_prio_alua
-rwxr-xr-x 1 root root 12088 Feb 3 12:49
-rwxr-xr-x 1 root root 12056 Sep 2 23:03 /sbin/mpath_prio_alua
[root@ca-devapm-73 lib]# /sbin/mpath_prio_alua -v /dev/sdh
Target port groups are not supported.
[root@ca-devapm-73 lib]# /sb/bwong/git-multipath-tools-inst/sbin/mpath_prio_alua
Target port groups are implicitly supported.
Reported target port group is 1 [active/non-optimized]
[root@ca-devapm-73 lib]# sg_inq /dev/sdh
PQual=0 Device_type=0 RMB=0 [ANSI_version=5] version=0x05
[AERC=0] [TrmTsk=0] NormACA=1 HiSUP=1 Resp_data_format=2
SCCS=0 ACC=0 ALUA=1 3PC=0 Protect=0
BQue=0 EncServ=0 MultiP=1 MChngr=0 [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1
Clocking=0x0 QAS=0 IUS=0
length=182 (0xb6) Peripheral device type: disk
Vendor identification: Pillar
Product identification: Axiom 500
Product revision level: 0000
Product serial number: 000B080000001321
I notice that sg_inq parses the relevant bit as ALUA=1 probably due to the
different inquiry spec revision.
Here's the relevant git commit log from Christophe's git tree...
author root <email@example.com> Fri, 26 Aug 2005 22:19:56 +0200
committer root <firstname.lastname@example.org> Fri, 26 Aug 2005 22:19:56 +0200
* path_priority/pp_alua/main.c, path_priority/pp_alua/rtpg.c,
[priority] update the alua prioritizer
Removes bitfields in the SCSI structs.
This didn't work on i386.
From Stefan Bader, IBM
I'll add to stefan's note that the bitfields broke x86_64 too ;-)
Created attachment 124134 [details]
patch made with cg-mkpatch -r 0803439535ea30ad1951d3deb0c5eaf894470d43 99c1a2e54868ab81b958fbe56858f1f889fd6e90
try this patch. it's the fix from the git tree.
Ahhh.. Everything makes more sense now.... I was looking at the current code,
not the U2 code. This change got picked up for the U3 release.
when is U3 getting released? it wasn't obvious to me how to locate this
information via the website.