Ich schreibe ein Drehbuch und bin daran interessiert, dieTransportklasse(fc – „Fibre Channel“, SCSI, ICSI usw.) für ein bestimmtes Blockgerät. Ich kann diese Informationen über ls -l /dev/disk/by-pathRHEL abrufen, aber ich würde lieber sysfs abfragen, wenn das überhaupt möglich ist (aus verschiedenen Gründen, einschließlich der Portabilität). Beispiel:
[root@localhost sde]# ls -l /dev/disk/by-path
total 0
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:1:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 21 16:39 pci-0000:01:00.0-scsi-0:2:2:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.0-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdd
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.0-fc-0x500601663ee0025f:0x0015000000000000 -> ../../sde
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.0-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdf
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.0-fc-0x5006016e3ee0025f:0x0015000000000000 -> ../../sdg
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.1-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdj
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.1-fc-0x500601653ee0025f:0x0015000000000000 -> ../../sdk
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.1-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdh
lrwxrwxrwx 1 root root 9 Jul 21 16:39 pci-0000:1a:00.1-fc-0x5006016d3ee0025f:0x0015000000000000 -> ../../sdi
Aber wenn ich hineinschaue, /sys/block/sdesehe ich nichts besonders Nützliches:
[root@localhost sde]# ls -l /sys/block/sde
total 0
-r--r--r-- 1 root root 4096 Oct 14 16:51 dev
lrwxrwxrwx 1 root root 0 Oct 14 16:51 device -> ../../devices/pci0000:00/0000:00:07.0/0000:1a:00.0/host5/rport-5:0-2/target5:0:0/5:0:0:21
drwxr-xr-x 2 root root 0 Jul 21 12:39 holders
drwxr-xr-x 3 root root 0 Jul 21 12:39 queue
-r--r--r-- 1 root root 4096 Oct 14 16:51 range
-r--r--r-- 1 root root 4096 Oct 14 16:51 removable
-r--r--r-- 1 root root 4096 Oct 14 16:51 size
drwxr-xr-x 2 root root 0 Jul 21 12:39 slaves
-r--r--r-- 1 root root 4096 Oct 14 16:51 stat
lrwxrwxrwx 1 root root 0 Oct 14 16:51 subsystem -> ../../block
--w------- 1 root root 4096 Oct 14 16:51 uevent
Ich bin für jede Hilfe dankbar, auch wenn sie mich nur in die richtige Richtung treibt. Meine ideale Lösung ist die Verwendung vonnurSysfs-Daten.
Antwort1
Sofern ich keine bessere Antwort bekomme, werde ich dies als meine Lösung nehmen. Es ist sehr indirekt, scheint aber zu funktionieren. Im Grunde habe ich davon ausgegangen, dass udevdder Pfad in erstellt werden konnte /dev/disk/by-path, esmussin sysfs sein, denn meines Wissens ist das alles, was udev wirklich tut: Es nimmt sysfs-Informationen und führt unter Verwendung dieser konfigurierte Aktionen aus.
Nach einigem Stöbern sieht es so aus, als würden diese Links durch den Inhalt der ID_PATHVariable erstellt, die über das /lib/udev/id_pathBash-Skript festgelegt wird. Darin habe ich eine Case-Anweisung gefunden, die im Wesentlichen darlegt, wie der Transport bestimmt wird, indem die Existenz verschiedener Verzeichnisse direkt unter dem Sysfs-Eintrag für den Quellcontroller des angegebenen Blockgeräts überprüft wird:
*/rport-[0-9]*:[0-9]*-[0-9]*/*)
handle_fc "$D"
;;
*/end_device-[0-9]*:[0-9]*:[0-9]*/*)
handle_sas "$D"
;;
*/fw-host[0-9]*/*)
handle_firewire "$D"
;;
*/session[0-9]*/*)
handle_iscsi "$D"
D=
;;
*/host[0-9]*/[0-9]*:[0-9]*:[0-9]*:[0-9]*)
handle_scsi "$D"
;;
*/usb[0-9]*/[0-9]*/*)
handle_usb "$D"
;;
*/pci[0-9]*:[0-9]*)
handle_pci "$D"
;;
*/serio[0-9]*)
handle_serio "$D"
;;
*/platform/*)
handle_platform "$D"
;;
*/devices)
D=
;;
Ich habe dies auf der Befehlszeile getestet, indem ich den Fibre-Channel-Test wiederholt habe, und habe positive Ergebnisse erhalten:
## INTERNAL DRIVE:
[root@localhost sde]# ls -ld /sys/block/sda/device/../../../rport* 2>/dev/null | wc -l
0
## FIBRE CHANNEL BLOCK DEVICE:
[root@localhost sde]# ls -ld /sys/block/sde/device/../../../rport* 2>/dev/null | wc -l
4
Im Grunde nehme ich den Kurznamen des Geräts (sda, sdb, sde usw.), gebe das physische Gerät ein und gehe dann weiter, ..bis ich beim Quellcontroller des Blockgeräts bin. Wenn der Sysfs-Eintrag des Controllers rport*Verzeichnisse als unmittelbare untergeordnete Elemente hat, bedeutet dies, dass das Blockgerät über Fibre Channel eingeht.
Dies repliziert nur die Prüfung für den ersten Switch Case ( */rport-[0-9]*:[0-9]*-[0-9]*/*)) für iscsi. Ich konnte den Erfolg auch reproduzieren, indem ich auf dem Controller nach „session[0-9]“-Verzeichnissen suchte:
[root@files2 ~]# ls -ld /sys/block/sda/device/../../../session[0-9]
drwxr-xr-x. 6 root root 0 Oct 15 13:50 /sys/block/sda/device/../../../session1
[root@files2 ~]#
Mein Skript wird in Python geschrieben, aber es sieht so aus, als ob es ausreicht, nach diesen Verzeichnissen zu suchen. Ich werde fortfahren und dies als meine Lösung markieren (sobald es mir möglich ist).
Antwort2
Außer meinem Fedora 19-System gibt es keine Systeme, auf denen ich dies testen könnte, aber dies könnte ein Anfang sein:
$ ls -l /sys/block/sda/subsystem/sda
lrwxrwxrwx. 1 root root 0 Oct 14 21:41 /sys/block/sda/subsystem/sda -> ../../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/
Es ist auch interessant festzustellen, dass mein System keine hat /dev/disk/by-path.