Linux Storage - systool fc_transport and fc_remote_ports

category: solutionz · date: 2013-12-31 · updated: 2026-10-03 · author: LALA

Linux Storage Solution · Config document · referenced from Linux HBA and SCSI inventory and SCSI addressing and FC names

The two systool listings on HV01 that show the other end of each FC link: the fc_transport class with the SCSI targets target1:0:0 and target2:0:0, and the fc_remote_ports class with the remote ports rport-1:0-0 and rport-2:0-0, which are the two 3PAR array ports the host is zoned to. Both ran as root on HV01 and read only.

Item	Value
Classes	`fc_transport` (`/sys/class/fc_transport/target1:0:0`, `target2:0:0`) and `fc_remote_ports` (`/sys/class/fc_remote_ports/rport-1:0-0`, `rport-2:0-0`)
On which host	`HV01`, the first blade (HP BL660c Gen8)
Run as	`root`
Tool	`systool` from the sysfsutils package; the notes do not give its version
Remote ports	one 3PAR port per HBA port: `0x21120002ac00abcd` behind `host1`, `0x20110002ac00abcd` behind `host2`, both with the node name `0x2ff70002ac00abcd`
Timeouts	`dev_loss_tmo 16`, `fast_io_fail_tmo off` on both remote ports; the notes do not say whether these were defaults or had been set

The commands

The FC transport class, one entry per SCSI target. The notes title it "Linux information about the HBA ports and cards: physical address, bus, driver", but what it lists is the target seen through each port, with the port's PCI path in the uevent.

bash

$ systool -c fc_transport -v

output 24 lines

Class = "fc_transport"
  Class Device = "0:0"
  Class Device path = "/sys/class/fc_transport/target1:0:0"
    node_name           = "0x2ff70002ac00abcd"
    port_id             = "0x2a0300"
    port_name           = "0x21120002ac00abcd"
    uevent              = "PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:03:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=qla2xxx"
    Device = "target1:0:0"
    Device path = "/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/host1/rport-1:0-0/target1:0:0"
      uevent              =

  Class Device = "0:0"
  Class Device path = "/sys/class/fc_transport/target2:0:0"
    node_name           = "0x2ff70002ac00abcd"
    port_id             = "0x580000"
    port_name           = "0x20110002ac00abcd"
    uevent              = "PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:03:00.1
PHYSDEVBUS=pci
PHYSDEVDRIVER=qla2xxx"
    Device = "target2:0:0"
    Device path = "/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.1/host2/rport-2:0-0/target2:0:0"
      uevent              =

The remote ports class, which the notes title "Linux information about the attached disk array and its ports".

bash

$ systool -c fc_remote_ports -v

output 37 lines

Class = "fc_remote_ports"

  Class Device = "0-0"
  Class Device path = "/sys/class/fc_remote_ports/rport-1:0-0"
    dev_loss_tmo        = "16"
    fast_io_fail_tmo    = "off"
    node_name           = "0x2ff70002ac00abcd"
    port_id             = "0x2a0300"
    port_name           = "0x21120002ac00abcd"
    port_state          = "Online"
    roles               = "FCP Target"
    scsi_target_id      = "0"
    supported_classes   = "Class 3"
    uevent              = "PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:03:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=qla2xxx"
    Device = "rport-1:0-0"
    Device path = "/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/host1/rport-1:0-0"
      uevent              =

  Class Device = "0-0"
  Class Device path = "/sys/class/fc_remote_ports/rport-2:0-0"
    dev_loss_tmo        = "16"
    fast_io_fail_tmo    = "off"
    node_name           = "0x2ff70002ac00abcd"
    port_id             = "0x580000"
    port_name           = "0x20110002ac00abcd"
    port_state          = "Online"
    roles               = "FCP Target"
    scsi_target_id      = "0"
    supported_classes   = "Class 3"
    uevent              = "PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:03:00.1
PHYSDEVBUS=pci
PHYSDEVDRIVER=qla2xxx"
    Device = "rport-2:0-0"
    Device path = "/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.1/host2/rport-2:0-0"
      uevent              =

The attributes

systool shortens the class device names: 0:0 is target1:0:0 and target2:0:0 with the host number dropped, 0-0 is rport-1:0-0 and rport-2:0-0. The full names are in the path lines.

Attribute	`rport-1:0-0` (behind `host1`)	`rport-2:0-0` (behind `host2`)	What it tells
`port_name`	`0x21120002ac00abcd`	`0x20110002ac00abcd`	the WWPN of the array port. `21:12:00:02:ac:00:ab:cd` is the port the switch notes alias as `Storage1-C0P0`, on `ext1`, 3PAR port `0:1:1` by the cabling schema (the port name itself decodes to node 1, see SCSI addressing and FC names); the second port is on `SW2`, which the notes do not configure
`node_name`	`0x2ff70002ac00abcd`	the same	the WWNN of the array; both ports belong to one node, `Storage1`
`port_id`	`0x2a0300`	`0x580000`	the FCID of the array port; `0x2a0300` is the FCID of `ext1` in VSAN 11 in the switch's `flogi` database
`port_state`	`Online`	`Online`	the remote port is logged in and reachable
`roles`	`FCP Target`	`FCP Target`	the remote port is a SCSI target; an HBA of another host would read `FCP Initiator`
`scsi_target_id`	`0`	`0`	the SCSI target ID the kernel gave this remote port, the third number of `host:bus:target:lun`; it is `0` on both hosts because each host sees one target
`supported_classes`	`Class 3`	`Class 3`	the FC service class
`dev_loss_tmo`	`16`	`16`	seconds the kernel keeps the SCSI devices behind the port after the port disappears before it deletes them. The notes do not say where `16` comes from; see the check below for what the driver source says
`fast_io_fail_tmo`	`off`	`off`	with a value, I/O to a lost port fails after that many seconds instead of waiting for `dev_loss_tmo`; `off` means it waits the full `dev_loss_tmo`. The notes do not say whether `16` and `off` were defaults or had been changed
`uevent`	the PCI path of `0000:03:00.0`	the PCI path of `0000:03:00.1`	the HBA port the remote port was seen through

The fc_transport entries carry the same node_name, port_id and port_name as the remote ports: the target is the remote port once the kernel has decided to scan it for SCSI devices. The hierarchy in the Device path lines reads PCI function, SCSI host, remote port, target, and the SCSI devices 1:0:0:0 to 1:0:0:5 and 1:0:0:254 hang below the target; they are listed in /proc/scsi/scsi.

Checked against Linux 7.2, RHEL 10.2, SLES 15 SP7 and the HPE host guides

As built	Today
`dev_loss_tmo 16`	Not a kernel default: the FC transport class defaults to 60 seconds, and `qla2xxx` overrides it with the HBA's port-down retry count, taken from the HBA NVRAM, or from the module parameter `qlport_down_retry` when that is not zero (30 if the NVRAM is invalid). With `qlport_down_retry 0` on this host, the `16` therefore most likely came out of the QMH2572's NVRAM; that the NVRAM held 16 is an inference from the output, the mechanism is in the driver source
`fast_io_fail_tmo off`	The state of a host without a multipath daemon: Red Hat sets it to 5 seconds when `multipathd` runs and leaves it `off` otherwise, and with `off` "no I/O fails until the device is removed from the system". Without `fast_io_fail_tmo`, `dev_loss_tmo` is capped at 600 seconds
no vendor guidance recorded	HPE's current 3PAR, Primera and Alletra guides set `fast_io_fail_tmo 10` and `dev_loss_tmo infinity` in the multipath device section (14 tolerated outside Peer Persistence), and the upstream multipath-tools table for `3PARdata VV` carries `fast_io_fail 10` and `dev_loss` infinity; SUSE recommends a high `dev_loss_tmo` because device removal "is prone to race conditions or deadlocks"
`fc_remote_ports` and `fc_transport` attributes	Unchanged in the FC transport class; the RHEL 10 storage guide documents the same files, `rport-H:B-R/` with `dev_loss_tmo` and `fast_io_fail_tmo`, `targetH:B:T/` with `port_id`, `node_name`, `port_name`
one remote port and one target per HBA, `scsi_target_id 0`	Unchanged addressing: Red Hat still defines H, B, T, L and R the same way

Red Hat adds a sentence worth repeating: consult the hardware vendor before changing any of these values on a host that runs multipath software. The notes show no vendor guidance and no test of a lost path.