question on hot plug removal and addition of a USB disk

question on hot plug removal and addition of a USB disk

[Sampathkumar, Kishore]

Scenario: I have a file system on a USB SCSI disk /dev/sdb mounted on /mnt.
I perform Action 1 below, and after some time, perform Action 2 below.

Action 1: removal (unplug) of a USB disk

At the time of removal of the USB disk, since the file system was mounted, is the reference to kobject corresponding (now orphaned) sdb still maintained in the kernel, although /dev/sdb is gone due to disk removal?

Is it that the old scsi_disk (sdb) still persists, but, the underlying scsi_dev is removed? Where should I start to trace the hotplug removal of the USB disk? What are the specific processing steps involved in the kernel to handle this (in terms of main routines handling this)?

Action 2: (hot) plug addition of the same USB SCSI disk

On plugging in the same USB SCSI disk, does the sd layer in scsi subsystem grab the first available 'free' sdX device (say sdp), given that sdb is still being referenced by the mounted file system?

Again, in terms of code, does this correspond to:
-	a new scsi_dev being allocated
-	a corresponding scsi_disk for sdp being allocated by the sd layer in scsi subsystem as part of 'probe' for the added SCSI device

Does the hot plugging work the same way for SAS disks attached behind a FC switch?

Thanks,
-	Kishore

No linkage from /sys entries for a given scsi_host to its PCI device details?

[Sampathkumar, Kishore]

[root@host26 /]# ls -l /dev/disk/by-id/wwn-0x5000c5000f8f4583
lrwxrwxrwx. 1 root root 9 Oct 19 11:14 wwn-0x5000c5000f8f4583 -> ../../sdg

[root@host26 /]# ls /sys/block/sdg/device/scsi_disk
3:0:5:0
^
|

The above is the host{number} for the SCSI Host controller (in the above case "host3").

[root@host26 /]# ls /sys/class/scsi_host/host3
active_mode     device            io_delay           scan            unchecked_isa_dma       version_nvdata_persistent
board_assembly  device_delay      logging_level      sg_tablesize    unique_id               version_product
board_name      fw_queue_depth    power              state           version_bios
board_tracer    fwfault_debug     proc_name          subsystem       version_fw
can_queue       host_busy         prot_capabilities  supported_mode  version_mpi
cmd_per_lun     host_sas_address  prot_guard_type    uevent          version_nvdata_default

>From the above, there is no linkage to the PCI device corresponding to the above host controller. The only way I could establish the linkage was to actually start from the PCI device ID for this controller, and then, doing the following:

[root@host26 /]# ls /sys/class/pci_bus/0000:0c/device/0000:0c:00.0
broken_parity_status  host3          numa_node  resource   subsystem_device
class                 irq            pools      resource0  subsystem_vendor
config                local_cpulist  power      resource1  uevent
device                local_cpus     remove     resource3  vendor
driver                modalias       rescan     rom        vpd
enable                msi_bus        reset      subsystem

I think it is very useful to have the necessary linkage to get to the PCI device from the /sys/class/scsi_host/host3 entries.

Thanks,
-	Kishore

RE: No linkage from /sys entries for a given scsi_host to its PCI device details?

[Sampathkumar, Kishore]

Same text as before; but properly formatted.

[root@host26 /]# ls -l /dev/disk/by-id/wwn-0x5000c5000f8f4583
lrwxrwxrwx. 1 root root 9 Oct 19 11:14 wwn-0x5000c5000f8f4583 -> ../../sdg

[root@host26 /]# ls /sys/block/sdg/device/scsi_disk
3:0:5:0

The above is the host{number} for the SCSI Host controller (in the above case "host3").

[root@host26 /]# ls /sys/class/scsi_host/host3
active_mode     device            io_delay           scan            unchecked_isa_dma       version_nvdata_persistent
board_assembly  device_delay      logging_level      sg_tablesize    unique_id               version_product
board_name      fw_queue_depth    power              state           version_bios
board_tracer    fwfault_debug     proc_name          subsystem       version_fw
can_queue       host_busy         prot_capabilities  supported_mode  version_mpi
cmd_per_lun     host_sas_address  prot_guard_type    uevent          version_nvdata_default

>From the above, there is no linkage to the PCI device corresponding to the above host controller. The only way I could establish the linkage was to actually start from the PCI device ID for this controller, and then, doing the following:

[root@host26 /]# ls /sys/class/pci_bus/0000:0c/device/0000:0c:00.0
broken_parity_status  host3          numa_node  resource   subsystem_device
class                 irq            pools      resource0  subsystem_vendor
config                local_cpulist  power      resource1  uevent
device                local_cpus     remove     resource3  vendor
driver                modalias       rescan     rom        vpd
enable                msi_bus        reset      subsystem

I think it is very useful to have the necessary linkage to get to the PCI device from the /sys/class/scsi_host/host3 entries.

Thanks,
-	Kishore
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: No linkage from /sys entries for a given scsi_host to its PCI device details?

[James Bottomley]

On Mon, 2011-10-24 at 13:20 +0530, Sampathkumar, Kishore wrote:
> From the above, there is no linkage to the PCI device corresponding to
> the above host controller. The only way I could establish the linkage
> was to actually start from the PCI device ID for this controller, and
> then, doing the following: 

I do 

ls -l /sys/class/scsi_host

To get this:

lrwxrwxrwx 1 root root 0 Oct 24 09:25 host0
-> ../../devices/pci0000:00/0000:00:1f.2/host0/scsi_host/host0/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host1
-> ../../devices/pci0000:00/0000:00:1f.2/host1/scsi_host/host1/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host2
-> ../../devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host3
-> ../../devices/pci0000:00/0000:00:1f.2/host3/scsi_host/host3/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host4
-> ../../devices/pci0000:00/0000:00:1f.2/host4/scsi_host/host4/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host5
-> ../../devices/pci0000:00/0000:00:1f.2/host5/scsi_host/host5/

Which allows an easy link back.

James