Linux Storage - /var/mpp files
Linux Storage Solution · Config document · referenced from RDAC multipath driver basics
600a0b80…) are made-up values of the right shape. The listing shows the state with both arrays known to the driver, which is the state that RDAC problems and LUN removal later undoes for the standby array.The persistent state of the RDAC (MPP) driver on mppsrv01: one .wwn file per disk array the driver has seen, named after the array's WWN, and devicemapping, which binds each array to a number. The files are kept by the driver (who writes them is not in the notes); mppUpdate -d <array> and mppUpdate -c edit devicemapping, and the .wwn file of an array that should be forgotten has to be removed by hand.
| Item | Value |
|---|---|
| Directory | /var/mpp |
| Host | mppsrv01, Red Hat Enterprise Linux AS 4, kernel 2.6.9-89.0.9.ELsmp |
| Files | 600a0b800012345600000000aabbcc01.wwn (DS5300-SITEA), 600a0b800012345700000000aabbcc02.wwn (DS5300-SITEB), devicemapping |
| Owner and mode | root root, -rw------- (600), as the listing shows |
| Written by | not in the notes; devicemapping is edited with mppUpdate |
| Taken | 7 September 2010, after both arrays had been found |
| Driver version | RDAC 09.03.0B05.0331 |
The listing
Everything ran as root on mppsrv01. The cat ./… commands use relative paths, so the working directory was /var/mpp. First the directory itself:
$ ls -ltr /var/mpp
output 3 lines
-rw------- 1 root root 361 Sep 7 11:57 600a0b800012345600000000aabbcc01.wwn -rw------- 1 root root 361 Sep 7 11:57 600a0b800012345700000000aabbcc02.wwn -rw------- 1 root root 15 Sep 7 12:17 devicemapping
The file of the main array, DS5300-SITEA:
$ cat ./600a0b800012345600000000aabbcc01.wwn
output 4 lines
H2C0T0 :Active :Active :DS5300-SITEA maxLun256:CAP 0 :CAP 1 :CAP 2 :CAP 3 :CBP 0 :CBP 1 :CBP 2 :CBP 3 : L001 :H0C0T0:01H1C0T0:01---------:---------:H0C0T1:01H1C0T1:01---------:---------: L002 :H0C0T0:02H1C0T0:02---------:---------:H0C0T1:02H1C0T1:02---------:---------:
The file of the standby array, DS5300-SITEB:
$ cat ./600a0b800012345700000000aabbcc02.wwn
output 4 lines
H2C0T1 :Active :Active :DS5300-SITEB maxLun256:CAP 0 :CAP 1 :CAP 2 :CAP 3 :CBP 0 :CBP 1 :CBP 2 :CBP 3 : L001 :H1C0T2:01H0C0T3:01---------:---------:H1C0T3:01H0C0T2:01---------:---------: L002 :H1C0T2:02H0C0T3:02---------:---------:H1C0T3:02H0C0T2:02---------:---------:
The mapping of array numbers to array names:
$ cat /var/mpp/devicemapping
output 2 lines
0:DS5300-SITEA 1:DS5300-SITEB
Reading the .wwn file
The notes show the files without a legend. What follows is my reading of them, checked against the mppUtil -S and mppUtil -g 0 outputs in mppUtil commands, which use the same HxCyTz notation.
| Cell | Reading |
|---|---|
H2C0T0, H2C0T1 | the address of the array on the virtual MPP adapter: host 2, channel 0, target 0 for the first array and target 1 for the second. mppBusRescan later reports the standby array's disks as 2:0:1:1 and 2:0:1:2 |
Active, Active | the state of controller A and controller B; mppUtil -S prints the same two words in the same place |
DS5300-SITEA | the array name as the array reports it; it is also the directory name under /proc/mpp |
maxLun256 | the MaxLunsPerArray=256 of mpp.conf |
CAP 0–CAP 3, CBP 0–CBP 3 | eight path columns, four per controller, which is MaxPathsPerController=4; I read CAP as "controller A path" and CBP as "controller B path", a reading the mppUtil -g 0 output supports, since there controller A has the paths with target 0 and controller B those with target 1 |
L001, L002 | one row per LUN, LUN 1 and LUN 2 |
H0C0T0:01 | one path cell: physical host 0, channel 0, target 0, and LUN 01 on that path. The cells are written without a separator, so H0C0T0:01H1C0T0:01 is two cells |
--------- | an unused path slot |
For the main array the four paths of each LUN are therefore H0C0T0 and H1C0T0 to controller A and H0C0T1 and H1C0T1 to controller B: on both HBAs controller A is target 0 and controller B target 1. For the standby array the targets are 2 and 3, but the cells are crossed: H1C0T2 and H0C0T3 stand in the first two columns, H1C0T3 and H0C0T2 in the next two. If my reading of CAP and CBP is right, controller A is target 2 on host1 and target 3 on host0, which would be nothing more than a different discovery order on the two HBAs, as the target numbers come from the SCSI mid-layer in the order the HBA found the ports. The mppUtil -g 1 | grep PathId output in RDAC problems and LUN removal lists the paths of this array as targets 2, 2, 3, 3 for hosts 0, 1, 0, 1, which does not obviously agree with the crossing; the notes do not comment on either, so I leave the reading as a reading.
devicemapping is fifteen bytes, two lines: the number the driver uses for the array (the ID column of mppUtil -a, the argument of mppUtil -g) and the array name. The dates show that the .wwn files were written at 11:57 and devicemapping last at 12:17 on 7 September 2010, which is the morning the mppUtil examples were taken.
Checked against NetApp SANtricity 12.10 and the RDAC package readme
| As built | Today |
|---|---|
/var/mpp/devicemapping as the persistent binding of array numbers, edited with mppUpdate | The readme of the same build confirms the mechanism: changes to the "persistent binding file (/var/mpp/devicemapping)" need mppUpdate to rebuild the initrd. The readme also lists man pages RDAC, mppUtil, mppBusRescan and mppUpdate, which is where the .wwn format would have been documented if anywhere |
one .wwn file per array, kept by the driver | RDAC was discontinued with SANtricity OS 11.25. With DM-Multipath the kernel handler scsi_dh_rdac is attached automatically by vendor and product (IBM 1818 for the DS5000 family, among others), and there is no per-array state file of this kind |
| the two DS5300 arrays | The DS5300 (machine type 1818-53A) was withdrawn from marketing on 23 October 2012 and reached end of support on 31 January 2018 |