☰

¿Puedes identificar el transporte a través de sysfs?

tag-icon • tag-icon linux devices storage sysfs
¿Puedes identificar el transporte a través de sysfs?

Estoy escribiendo un guión y me interesa poder identificar elclase de transporte(fc - "canal de fibra", scsi, iscsi, etc.) para un dispositivo de bloque determinado. Puedo recuperar esta información a través ls -l /dev/disk/by-pathde RHEL, pero prefiero consultar sysfs si es posible (por diversas razones, incluida la portabilidad). Por ejemplo:

[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

Pero mirando /sys/block/sdeno veo nada particularmente útil:

[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

Se agradece cualquier ayuda, incluso si sólo me empuja en la dirección correcta. Mi solución ideal es utilizarsolodatos del sistema.

Respuesta1

A menos que obtenga una mejor respuesta, tomaré esto como mi solución. Es muy indirecto pero parece funcionar. Básicamente, lo juzgué por el hecho de que udevdfue capaz de hacer el camino en /dev/disk/by-pathél.debeestar en sysfs porque, que yo sepa, eso es todo lo que realmente hace udev: toma información de sysfs y realiza acciones configuradas utilizándola.

Después de hurgar, parece que esos enlaces se crean mediante el contenido de la ID_PATHvariable que se establece mediante el /lib/udev/id_pathscript bash. Dentro de eso encontré una declaración de caso que básicamente establece cómo determina el transporte al verificar la existencia de varios directorios directamente debajo de la entrada sysfs para el controlador de origen del dispositivo de bloque dado:

                    */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=
                            ;;

Probé esto en la línea de comando replicando la prueba Fibre Channel y obtuve resultados positivos:

## 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

Básicamente, tomo el nombre corto del dispositivo (sda, sdb, sde, etc.), ingreso el dispositivo físico y luego ..hasta que estoy en el controlador de fuente del dispositivo de bloque. Si la entrada sysfs del controlador tiene rport*directorios como hijos inmediatos, eso significa que el dispositivo de bloque ingresa a través de canal de fibra.

Esto solo replica la verificación del primer caso de cambio ( */rport-[0-9]*:[0-9]*-[0-9]*/*)) para iscsi. También pude replicar el éxito buscando los directorios "sesión [0-9]" en el controlador:

[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 ~]#

Mi script se escribirá en Python, pero parece que basta con comprobar estos directorios. Voy a seguir adelante y marcar esto como mi solución (una vez que me lo permita de todos modos).

Respuesta2

No hay sistemas para probar esto aparte de mi sistema Fedora 19, pero esto puede ser un comienzo:

$ 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/

También es interesante notar que mi sistema no tiene /dev/disk/by-path.

información relacionada