☰

Você consegue identificar o transporte via sysfs?

tag-icon • tag-icon linux devices storage sysfs
Você consegue identificar o transporte via sysfs?

Estou escrevendo um roteiro e estou interessado em poder identificar oclasse de transporte(fc - "fibre channel", scsi, iscsi, etc.) para um determinado dispositivo de bloco. Posso recuperar essas informações no ls -l /dev/disk/by-pathRHEL, mas prefiro consultar o sysfs se isso for possível (por vários motivos, incluindo portabilidade). Por exemplo:

[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

Mas olhando /sys/block/sdenão vejo 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

Qualquer ajuda é apreciada, mesmo que apenas me empurre na direção certa. Minha solução ideal é usarapenasdados sysfs.

Responder1

A menos que eu obtenha uma resposta melhor, tomarei isso como minha solução. É muito indireto, mas parece funcionar. Basicamente, julguei pelo fato de udevdter conseguido fazer o caminho /dev/disk/by-path,deveestar no sysfs porque, pelo que sei, isso é tudo que o udev realmente faz: pega informações do sysfs e executa ações configuradas utilizando-as.

Depois de vasculhar, parece que esses links foram criados pelo conteúdo da ID_PATHvariável que é definida por meio do /lib/udev/id_pathscript bash. Dentro dela, encontrei uma declaração de caso que basicamente descreve como ela determina o transporte, verificando a existência de vários diretórios diretamente abaixo da entrada sysfs para o controlador de origem do dispositivo de bloco fornecido:

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

Testei isso na linha de comando replicando o teste Fibre Channel e obtive 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

Basicamente, pego o nome abreviado do dispositivo (sda, sdb, sde, etc), insiro o dispositivo físico e até ..chegar ao controlador de origem do dispositivo de bloco. Se a entrada sysfs do controlador tiver rport*diretórios como filhos imediatos, isso significa que o dispositivo de bloco está entrando via Fibre Channel.

Isso apenas replica a verificação do primeiro switch case ( */rport-[0-9]*:[0-9]*-[0-9]*/*)) para iscsi. Também consegui replicar o sucesso procurando os diretórios "session[0-9]" no 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 ~]#

Meu script será escrito em Python, mas parece que a verificação desses diretórios é suficiente. Vou prosseguir e marcar isso como minha solução (uma vez que isso me permita, de qualquer maneira).

Responder2

Nenhum sistema para testar isso além do meu sistema Fedora 19, mas isso pode ser um começo:

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

Também é interessante notar que meu sistema não possui arquivos /dev/disk/by-path.

informação relacionada