Re: Ordering problems with 3ware controller

[Donald Buczek]

On 17.11.2016 15:55, Paul Menzel wrote:


Dear Linux folks,


On 11/16/16 22:24, Donald Buczek wrote:


The relevant commit is 703b5fa  which includes


The commit message summary is *fs/dcache.c: Save one 32-bit multiply 
in dcache lookup*.



 static inline unsigned long end_name_hash(unsigned long hash)
 {
-   return (unsigned int)hash;
+   return __hash_32((unsigned int)hash);
 }

__hash_32 is a multiplication by 0x61C88647 ( hash.h )

And this exactly is the difference between the hash value of "host0" on
the 4.4 and the 4.8 system:

  DB<2> x sprintf '%x',0x11bf1ddd*0x61C88647
0  '6c750ef074af64b'

The bug, of course, is in the userspace tool tw_cli which wrongly
assumes that the names would be returned in the "right" order by 
getdents.


Nice analysis.

Unfortunately, I don’t find the discussion of the patch on the Linux 
kernel mailing list.


703b5fa sits on top of 8387ff2 from Linus Torvalds. Maybe he didn't send 
his own suggestion to the lists but to the three people named in that 
commit only. Maybe George Spelvin replied with his patch as an 
improvement and Linus just accepted it on his own branch and merged 
(554828e).


Donald

--
Donald Buczek
buc...@molgen.mpg.de
Tel: +49 30 8413 1433

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ordering problems with 3ware controller

[Paul Menzel]

Dear Linux folks,


On 11/16/16 22:24, Donald Buczek wrote:

On 10.11.2016 14:59, Martin K. Petersen wrote:

"Paul" == Paul Menzel  writes:



Linux does not provide device discovery ordering guarantees. You need
to fix your scripts to use UUIDs, filesystem labels, or DM devices to
get stable naming.

Paul> Indeed. But it worked for several years, so that *something* must
Paul> have changed that the ordering of the result of `getdents64` is
Paul> different now.

Could be changes in the PCI or platform code that causes things to be
enumerated differently. Whatever it is, it has nothing to do with the
3ware drivers themselves since they have been dormant for a long time.



Right. We further tracked it down. In fact its not a matter of driver
initialization order but of the way sysfs/kernfs hashes its object names
and thereby defines the order of names returned by getdents64 calls. In
fs/kernfs/dir.h the names are inserted into a red-black tree ordered by
the hashes over their names (and possibly namespace pointer, which in
our case is zero).

I've walked the rbtrees of the kernfs_node structs from
/sys/class/scsi_host showing their addresses, the hash values and the
names in a 4.4.27 system:

root:cu:/home/buczek/autofs/# ./peek-3w

88046d847640 : 11bf1ddd : host0
88046c56d3e8 : 11bf1e8d : host1
88046c571c58 : 11bf1f3d : host2
88046c572550 : 11bf1fed : host3
88046c577dc0 : 11bf209d : host4
88046a4bbaf0 : 11bf214d : host5

As can be seen, in 4.4 the hash algorithm happened to produce increasing
hash values for names like "host0","host1","host2",... In 4.8.6 the hash
values seem to be more random:

root:gynaekophobie:/home/buczek/autofs/# ./peek-3w

88041df9a7f8 : 074af64b : host0
88081db40528 : 1009cd9b : host9
88041d3fba50 : 1c512bfb : host7
88181d19c000 : 28988a5b : host5
88041df5a780 : 34dfe8bb : host3
88041d3f5e10 : 4127471b : host1
88041ccbd258 : 562d7ccb : host8
88201cd5f960 : 6274db2b : host6
88141e2d0ca8 : 6ebc398b : host4
88041df599d8 : 7b0397eb : host2

The relevant commit is 703b5fa  which includes


The commit message summary is *fs/dcache.c: Save one 32-bit multiply in 
dcache lookup*.



 static inline unsigned long end_name_hash(unsigned long hash)
 {
-   return (unsigned int)hash;
+   return __hash_32((unsigned int)hash);
 }

__hash_32 is a multiplication by 0x61C88647 ( hash.h )

And this exactly is the difference between the hash value of "host0" on
the 4.4 and the 4.8 system:

  DB<2> x sprintf '%x',0x11bf1ddd*0x61C88647
0  '6c750ef074af64b'

The bug, of course, is in the userspace tool tw_cli which wrongly
assumes that the names would be returned in the "right" order by getdents.


Nice analysis.

Unfortunately, I don’t find the discussion of the patch on the Linux 
kernel mailing list.


Searching for the summary only brings up *screen rotation flipped in 
4.8-rc* [1].



As a dirty workaround, I've created a new wrapper, which uses ptrace to
pause the program on return from SYS_getdents64 and sorts the values
returned from the system call in the memory of the target process. >



I append the source of the wrapper.



Kind regards,

Paul


[1] https://lkml.org/lkml/2016/8/30/739
"screen rotation flipped in 4.8-rc"
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ordering problems with 3ware controller

[Donald Buczek]

On 10.11.2016 14:59, Martin K. Petersen wrote:

"Paul" == Paul Menzel  writes:

Paul,


Linux does not provide device discovery ordering guarantees. You need
to fix your scripts to use UUIDs, filesystem labels, or DM devices to
get stable naming.

Paul> Indeed. But it worked for several years, so that *something* must
Paul> have changed that the ordering of the result of `getdents64` is
Paul> different now.

Could be changes in the PCI or platform code that causes things to be
enumerated differently. Whatever it is, it has nothing to do with the
3ware drivers themselves since they have been dormant for a long time.



Right. We further tracked it down. In fact its not a matter of driver 
initialization order but of the way sysfs/kernfs hashes its object names 
and thereby defines the order of names returned by getdents64 calls. In 
fs/kernfs/dir.h the names are inserted into a red-black tree ordered by 
the hashes over their names (and possibly namespace pointer, which in 
our case is zero).


I've walked the rbtrees of the kernfs_node structs from 
/sys/class/scsi_host showing their addresses, the hash values and the 
names in a 4.4.27 system:


root:cu:/home/buczek/autofs/# ./peek-3w

88046d847640 : 11bf1ddd : host0
88046c56d3e8 : 11bf1e8d : host1
88046c571c58 : 11bf1f3d : host2
88046c572550 : 11bf1fed : host3
88046c577dc0 : 11bf209d : host4
88046a4bbaf0 : 11bf214d : host5

As can be seen, in 4.4 the hash algorithm happened to produce increasing 
hash values for names like "host0","host1","host2",... In 4.8.6 the hash 
values seem to be more random:


root:gynaekophobie:/home/buczek/autofs/# ./peek-3w

88041df9a7f8 : 074af64b : host0
88081db40528 : 1009cd9b : host9
88041d3fba50 : 1c512bfb : host7
88181d19c000 : 28988a5b : host5
88041df5a780 : 34dfe8bb : host3
88041d3f5e10 : 4127471b : host1
88041ccbd258 : 562d7ccb : host8
88201cd5f960 : 6274db2b : host6
88141e2d0ca8 : 6ebc398b : host4
88041df599d8 : 7b0397eb : host2

The relevant commit is 703b5fa  which includes

 static inline unsigned long end_name_hash(unsigned long hash)
 {
-   return (unsigned int)hash;
+   return __hash_32((unsigned int)hash);
 }

__hash_32 is a multiplication by 0x61C88647 ( hash.h )

And this exactly is the difference between the hash value of "host0" on 
the 4.4 and the 4.8 system:


  DB<2> x sprintf '%x',0x11bf1ddd*0x61C88647
0  '6c750ef074af64b'

The bug, of course, is in the userspace tool tw_cli which wrongly 
assumes that the names would be returned in the "right" order by getdents.


As a dirty workaround, I've created a new wrapper, which uses ptrace to 
pause the program on return from SYS_getdents64 and sorts the values 
returned from the system call in the memory of the target process.


I append the source of the wrapper.
--

Donald Buczek
buc...@molgen.mpg.de
Tel: +49 30 8413 1433

#define _GNU_SOURCE /* See feature_test_macros(7) */
#include 
#include/* For SYS_xxx definitions */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

typedef uint64_t u64;
typedef int64_t s64;

/* from include/linux/dirent.h : */

struct linux_dirent64 {
u64 d_ino;
s64 d_off;
unsigned short  d_reclen;
unsigned char   d_type;
chard_name[0];
};

void die(char *fmt,...) {
	va_list ap;
	va_start(ap,fmt);
	vfprintf(stderr,fmt,ap);
	exit(1);
}

void die_regerror(int status,regex_t *re) {
	char msg[80];
	int s;
	s=regerror(status,re,msg,sizeof(msg));
	die("regex: %s\n",msg);
}

int hostnum(char *hostname) {
	static regex_t *re=NULL;
	int status;
	regmatch_t match[2];

	if (!re) {
		re=malloc(sizeof(*re));
		if (!re) die("");
		status=regcomp(re,"^host([0-9]+)$",REG_EXTENDED);
		if (status) die_regerror(status,re);
	}

	status=regexec(re,hostname,sizeof(match)/sizeof(*match),match,0);
	if (status==0) {
		char c=hostname[match[1].rm_eo];
		match[1].rm_eo='\0';
		int num=atoi([match[1].rm_so]);
		match[1].rm_eo=c;
		return(num);
	} else if (status==REG_NOMATCH) {
		return(-1);
	} else {
		die_regerror(status,re);
	}
}

struct sortentry {
	struct linux_dirent64 *dirent;
	int hostnum;
};

int compare_sortentry(const void *vp1,const void *vp2) {
	struct sortentry *p1=(struct sortentry *)vp1;
	struct sortentry *p2=(struct sortentry *)vp2;

	if (p1->hostnum!=-1 && p2->hostnum!=-1) {
		return p1->hostnumhostnum ? -1 : p1->hostnum>p2->hostnum ? 1 : 0;
	}
	return strcmp(p1->dirent->d_name,p2->dirent->d_name);
}

void fix_memory(pid_t pid,size_t count,void *dirp) {

	char *memfilename;
	int fd;

	char *dirents_unsorted,*dirents_sorted;
	struct sortentry *sort_array;
	struct sortentry *sort_entry;

	size_t s;

	int entry_count;
	int bpos;
	int i;

	struct linux_dirent64 *d;

	if (count==0) return;

	if (asprintf(,"/proc/%d/mem",pid)==-1) die("%m\n");

	fd=open(memfilename,O_RDWR);
	

Re: Ordering problems with 3ware controller

[Martin K. Petersen]

> "Paul" == Paul Menzel  writes:

Paul,

>> Linux does not provide device discovery ordering guarantees. You need
>> to fix your scripts to use UUIDs, filesystem labels, or DM devices to
>> get stable naming.

Paul> Indeed. But it worked for several years, so that *something* must
Paul> have changed that the ordering of the result of `getdents64` is
Paul> different now.

Could be changes in the PCI or platform code that causes things to be
enumerated differently. Whatever it is, it has nothing to do with the
3ware drivers themselves since they have been dormant for a long time.

Paul> Fixing the scripts is unfortunately not that easy, as `tw_cli` is
Paul> a proprietary tool [1], and we do not have the sources. It does a
Paul> `readdir()`.

That's beside the point. Whatever you are doing that needs to address a
specific physical controller needs to use a different scheme than
discovery order to do so. Don't know if these cards provide a device
identification VPD or something with a serial number that you could key
off of?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ordering problems with 3ware controller

[Paul Menzel]

Dear Martin,


On 11/09/16 00:45, Martin K. Petersen wrote:

"Paul" == Paul Menzel  writes:



Paul> Updating from Linux 4.4.X to Linux 4.8.4, we noticed that the
Paul> 3ware devices under `/dev` – `/dev/twa0`, `/dev/twa1`, … – map to
Paul> the controllers differently.

Paul> This unfortunately breaks quite a lot of our scripts, as we depend
Paul> on the fact that the first controller is also in the front.

It's not the 3ware drivers since they have not been updated in a long
time (since way before 4.4).


Yes, that’s what made me wonder too.


Linux does not provide device discovery ordering guarantees. You need to
fix your scripts to use UUIDs, filesystem labels, or DM devices to get
stable naming.


Indeed. But it worked for several years, so that *something* must have 
changed that the ordering of the result of `getdents64` is different now.


Fixing the scripts is unfortunately not that easy, as `tw_cli` is a 
proprietary tool [1], and we do not have the sources. It does a `readdir()`.



open("/proc/scsi/3w-9xxx", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No 
such file or directory)
open("/sys/class/scsi_host", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
getdents64(3, /* 12 entries */, 4096)   = 368
stat("/sys/class/scsi_host/host0/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host9/stats", {st_mode=S_IFREG|0444, st_size=4096, 
...}) = 0
open("/sys/class/scsi_host/host9/stats", O_RDONLY) = 4
read(4, "3w-9xxx Driver v", 16) = 16
close(4)= 0
open("/dev/twa0", O_RDWR)   = 4
close(4)= 0
stat("/sys/class/scsi_host/host7/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host5/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host3/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host1/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host8/stats", {st_mode=S_IFREG|0444, st_size=4096, 
...}) = 0
open("/sys/class/scsi_host/host8/stats", O_RDONLY) = 4
read(4, "3w-9xxx Driver v", 16) = 16
close(4)= 0
open("/dev/twa1", O_RDWR)   = 4
close(4)= 0
stat("/sys/class/scsi_host/host6/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host4/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host2/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
open("/proc/devices", O_RDONLY) = 3


Please find attached a wrapper from my colleague, using name spaces to 
ensure the ordering, that `tw_cli` expects.



Kind regards,

Paul


[1] https://wiki.hetzner.de/index.php/3Ware_RAID_Controller/en
#! /usr/bin/perl
use strict;
use warnings;

sub sort_host {
my ($n1,$n2);
($n1)=$a=~/^host(\d+)$/ and ($n2)=$b=~/^host(\d+)$/ and return $n1 <=> 
$n2;
return $a cmp $b;
}


our $SYS_unshare=272;  # /usr/include/asm/unistd_64.h
our $CLONE_NEWNS=0x2;  # /usr/include/linux/sched.h

my $pid=fork;
defined $pid or die "$!\n";
unless ($pid) {
opendir my $d,"/sys/class/scsi_host";
my @names=sort sort_host grep !/^\.\.?$/,readdir $d;

syscall($SYS_unshare,$CLONE_NEWNS) and die "$!\n";
-d '/tmp/sysfs' or mkdir("/tmp/sysfs") or die "/tmp/sysfs: $!\n";
system 'mount','-tsysfs','BLA','/tmp/sysfs' and exit 1;
system 'mount','-ttmpfs','BLA','/sys/class/scsi_host' and exit 1;

for my $name (reverse @names) {

symlink("/tmp/sysfs/class/scsi_host/$name","/sys/class/scsi_host/$name") or die 
"/sys/class/scsi_host/$name: $!\n";
}
exec '/root/bin/tw_cli.exe',@ARGV;
die "$!\n";
}
wait;
$? and exit 1;

Re: Ordering problems with 3ware controller

[Martin K. Petersen]

> "Paul" == Paul Menzel  writes:

Paul,

Paul> Updating from Linux 4.4.X to Linux 4.8.4, we noticed that the
Paul> 3ware devices under `/dev` – `/dev/twa0`, `/dev/twa1`, … – map to
Paul> the controllers differently.

Paul> This unfortunately breaks quite a lot of our scripts, as we depend
Paul> on the fact that the first controller is also in the front.

It's not the 3ware drivers since they have not been updated in a long
time (since way before 4.4).

Linux does not provide device discovery ordering guarantees. You need to
fix your scripts to use UUIDs, filesystem labels, or DM devices to get
stable naming.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ordering problems with 3ware controller

[Paul Menzel]

Dear Linux SCSI folks,


On 11/08/16 11:07, Paul Menzel wrote:


Updating from Linux 4.4.X to Linux 4.8.4, we noticed that the 3ware
devices under `/dev` – `/dev/twa0`, `/dev/twa1`, … – map to the
controllers differently.

This unfortunately breaks quite a lot of our scripts, as we depend on
the fact that the first controller is also in the front.


$ dmesg | grep 3ware
[   14.509238] 3ware 9000 Storage Controller device driver for Linux
v2.26.02.014.
[   14.824274] scsi host8: 3ware 9000 Storage Controller
[   14.824537] 3w-9xxx: scsi8: Found a 3ware 9000 Storage Controller
at 0xd020, IRQ: 17.
[   15.508310] scsi host9: 3ware 9000 Storage Controller
[   15.508569] 3w-9xxx: scsi9: Found a 3ware 9000 Storage Controller
at 0xda10, IRQ: 17.


Tracing `twi_cli` it looks like the ordering of the devices in
`/sys/class/scsi_host` might have changed, as `getdents64` seems to be
used for the ordering of creating `/dev/twaX`.


$ find /sys/class/scsi_host/ -ls
 6033  0 drwxr-xr-x   2  root system  0 Nov  8
10:58 /sys/class/scsi_host/
23125  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host0 ->
../../devices/pci:00/:00:07.0/ata1/host0/scsi_host/host0
29893  0 lrwxrwxrwx   1  root system  0 Oct 27
18:03 /sys/class/scsi_host/host9 ->
../../devices/pci:80/:80:0e.0/:90:00.0/host9/scsi_host/host9
23878  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host7 ->
../../devices/pci:80/:80:08.0/ata8/host7/scsi_host/host7
23640  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host5 ->
../../devices/pci:80/:80:07.0/ata6/host5/scsi_host/host5
23402  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host3 ->
../../devices/pci:00/:00:08.0/ata4/host3/scsi_host/host3
23164  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host1 ->
../../devices/pci:00/:00:07.0/ata2/host1/scsi_host/host1
29851  0 lrwxrwxrwx   1  root system  0 Oct 27
18:03 /sys/class/scsi_host/host8 ->
../../devices/pci:00/:00:0e.0/:05:00.0/host8/scsi_host/host8
23839  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host6 ->
../../devices/pci:80/:80:08.0/ata7/host6/scsi_host/host6
23601  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host4 ->
../../devices/pci:80/:80:07.0/ata5/host4/scsi_host/host4
23363  0 lrwxrwxrwx   1  root system  0 Oct 27
17:41 /sys/class/scsi_host/host2 ->
../../devices/pci:00/:00:08.0/ata3/host2/scsi_host/host2
$ sudo -i tw_cli show

Ctl   Model(V)Ports  Drives   Units   NotOpt  RRate   VRate  BBU

c89650SE-8LPML 8 81   0   5   1  OK
c99690SA-8E0 00   0   5   1  OK

Enclosure Slots  Drives  Fans  TSUnits  PSUnits  Alarms
--
/c9/e016 0   3 121


So in this case `c8` is mapped to `/dev/twa1`, and `c9` to `/dev/twa0`.

As we do not know of a way, to use `tw_cli` to find the correct mapping,
or another place, we rely on the implicit ordering, which – according to
my colleagues – has worked for over 15 years [1].


Here is the excerpt from the manual page for smartctl [2].

> --- end of manual page excerpt ---

3ware,N  -  [FreeBSD  and Linux only] the device consists of one or more ATA 
disks con‐
nected to a 3ware RAID controller.  The non-negative integer N (in the range 
from 0  to
127 inclusive) denotes which disk on the controller is monitored.  Use syntax 
such as:
smartctl -a -d 3ware,2 /dev/sda
smartctl -a -d 3ware,0 /dev/twe0
smartctl -a -d 3ware,1 /dev/twa0
smartctl -a -d 3ware,1 /dev/twl0
The  first  two  forms, which refer to devices /dev/sda-z and /dev/twe0-15, may 
be used
with 3ware series 6000, 7000, and 8000 series controllers that use the 3x-  
driver.
Note  that  the /dev/sda-z form is deprecated starting with the Linux 2.6 
kernel series
and may not be supported by the Linux kernel in the near future.  The final 
form, which
refers  to devices /dev/twa0-15, must be used with 3ware 9000 series 
controllers, which
use the 3w-9xxx driver.

The devices /dev/twl0-15 must be used with the 3ware/LSI 9750 series 
controllers  which
use the 3w-sas driver.

Note  that if the special character device nodes /dev/twl?, /dev/twa?  and 
/dev/twe? do
not exist, or exist with the incorrect major or minor numbers, smartctl  will  
recreate
them  on  the  fly.   Typically  /dev/twa0  refers to the first 9000-series 
controller,
/dev/twa1 refers to the second 9000  series  controller,  and  so  on.   The  
/dev/twl0
devices  refers  to  the  first 

Ordering problems with 3ware controller

[Paul Menzel]

Dear Linux SCSI folks,


Updating from Linux 4.4.X to Linux 4.8.4, we noticed that the 3ware 
devices under `/dev` – `/dev/twa0`, `/dev/twa1`, … – map to the 
controllers differently.


This unfortunately breaks quite a lot of our scripts, as we depend on 
the fact that the first controller is also in the front.



$ dmesg | grep 3ware
[   14.509238] 3ware 9000 Storage Controller device driver for Linux 
v2.26.02.014.
[   14.824274] scsi host8: 3ware 9000 Storage Controller
[   14.824537] 3w-9xxx: scsi8: Found a 3ware 9000 Storage Controller at 
0xd020, IRQ: 17.
[   15.508310] scsi host9: 3ware 9000 Storage Controller
[   15.508569] 3w-9xxx: scsi9: Found a 3ware 9000 Storage Controller at 
0xda10, IRQ: 17.


Tracing `twi_cli` it looks like the ordering of the devices in 
`/sys/class/scsi_host` might have changed, as `getdents64` seems to be 
used for the ordering of creating `/dev/twaX`.



$ find /sys/class/scsi_host/ -ls
 6033  0 drwxr-xr-x   2  root system  0 Nov  8 10:58 
/sys/class/scsi_host/
23125  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host0 -> 
../../devices/pci:00/:00:07.0/ata1/host0/scsi_host/host0
29893  0 lrwxrwxrwx   1  root system  0 Oct 27 18:03 
/sys/class/scsi_host/host9 -> 
../../devices/pci:80/:80:0e.0/:90:00.0/host9/scsi_host/host9
23878  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host7 -> 
../../devices/pci:80/:80:08.0/ata8/host7/scsi_host/host7
23640  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host5 -> 
../../devices/pci:80/:80:07.0/ata6/host5/scsi_host/host5
23402  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host3 -> 
../../devices/pci:00/:00:08.0/ata4/host3/scsi_host/host3
23164  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host1 -> 
../../devices/pci:00/:00:07.0/ata2/host1/scsi_host/host1
29851  0 lrwxrwxrwx   1  root system  0 Oct 27 18:03 
/sys/class/scsi_host/host8 -> 
../../devices/pci:00/:00:0e.0/:05:00.0/host8/scsi_host/host8
23839  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host6 -> 
../../devices/pci:80/:80:08.0/ata7/host6/scsi_host/host6
23601  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host4 -> 
../../devices/pci:80/:80:07.0/ata5/host4/scsi_host/host4
23363  0 lrwxrwxrwx   1  root system  0 Oct 27 17:41 
/sys/class/scsi_host/host2 -> 
../../devices/pci:00/:00:08.0/ata3/host2/scsi_host/host2
$ sudo -i tw_cli show

Ctl   Model(V)Ports  Drives   Units   NotOpt  RRate   VRate  BBU

c89650SE-8LPML 8 81   0   5   1  OK
c99690SA-8E0 00   0   5   1  OK

Enclosure Slots  Drives  Fans  TSUnits  PSUnits  Alarms
--
/c9/e016 0   3 121


So in this case `c8` is mapped to `/dev/twa1`, and `c9` to `/dev/twa0`.

As we do not know of a way, to use `tw_cli` to find the correct mapping, 
or another place, we rely on the implicit ordering, which – according to 
my colleagues – has worked for over 15 years [1].


Do you know of a way, to either get the mapping “over an API” so we 
don’t have to rely on the implicit ordering?


Otherwise, do you know, why the ordering has changed, and can this be 
reverted?



Kind regards,

Paul Menzel


[1] 
https://www.thomas-krenn.com/de/wiki/Smartmontools_mit_3ware_RAID_Controller

(German)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html