sysfs를 통한 전송을 식별할 수 있습니까?

sysfs를 통한 전송을 식별할 수 있습니까?

저는 스크립트를 작성하고 있는데, 스크립트를 식별하는 데 관심이 있습니다.운송 클래스(fc - "파이버 채널", scsi, iscsi 등) 특정 블록 장치에 대한 것입니다. RHEL을 통해 이 정보를 검색할 수 있지만 ls -l /dev/disk/by-path가능하다면(이식성을 포함한 다양한 이유로) sysfs에 쿼리하는 것이 좋습니다. 예를 들어:

[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

하지만 살펴보니 /sys/block/sde특별히 유용한 내용은 없습니다.

[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

비록 그것이 나를 올바른 방향으로 밀어주더라도 도움을 주시면 감사하겠습니다. 내 이상적인 솔루션은 다음을 사용하는 것입니다.오직sysfs 데이터.

답변1

더 나은 답변을 얻지 못하면 이것을 해결책으로 삼겠습니다. 매우 간접적이지만 작동하는 것 같습니다. 기본적으로는 에서 udevd길을 만들 수 있었다고 판단했다 /dev/disk/by-path.~ 해야 하다내가 아는 바로는 udev가 실제로 수행하는 작업은 sysfs에 있습니다. sysfs 정보를 가져와 이를 활용하여 구성된 작업을 수행합니다.

ID_PATH주변을 뒤져본 후에는 bash 스크립트 를 통해 설정된 변수 의 내용에 의해 해당 링크가 생성되는 것처럼 보입니다 /lib/udev/id_path. 그 안에서 나는 주어진 블록 장치의 소스 컨트롤러에 대한 sysfs 항목 바로 아래에 다양한 디렉터리가 있는지 확인하여 전송을 결정하는 방법을 기본적으로 설명하는 사례 설명을 발견했습니다.

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

Fibre Channel 테스트를 복제하여 명령줄에서 이를 테스트한 결과 긍정적인 결과를 얻었습니다.

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

기본적으로 장치의 짧은 이름(sda, sdb, sde 등)을 사용하여 물리적 장치에 들어간 다음 ..블록 장치의 소스 컨트롤러에 도달할 때까지 진행합니다. 컨트롤러의 sysfs 항목 rport*에 직계 하위 디렉터리가 있는 경우 이는 블록 장치가 파이버 채널을 통해 들어오고 있음을 의미합니다.

이는 iscsi의 첫 번째 스위치 케이스( )에 대한 검사만 복제하며 */rport-[0-9]*:[0-9]*-[0-9]*/*), 컨트롤러에서 "session[0-9]" 디렉터리를 찾아 성공을 복제할 수도 있습니다.

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

내 스크립트는 Python으로 작성될 예정이지만 이러한 디렉터리를 확인하는 것만으로도 충분해 보입니다. 나는 이것을 내 솔루션으로 표시할 것입니다(어쨌든 허용되면).

답변2

Fedora 19 시스템 외에는 이를 테스트할 시스템이 없지만 이것이 시작일 수 있습니다.

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

내 시스템에 /dev/disk/by-path.

관련 정보