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ました。〜しなければならないsysfsでは、私が知っている限り、udevが実際にやっていることがすべてだからです。 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=
                            ;;

ファイバーチャネルテストをコピーしてコマンドラインでテストした結果、肯定的な結果が得られました。

## 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で書かれていますが、このディレクトリをチェックするだけで十分です。引き続きこれを私の解決策としてマークします(とにかく許可されたらすぐ)。

おすすめ記事