Gal Rosen wrote:
> I will try to make my question more clear.
> I would like to put a box between the client and the storage, and to be
> fully transparent against the host. All changes on the storage
> (add/remove/extend devices) should be present automatically to the
> client. In a direct connection between client and storage the
> administrator will coordinate between the client and storage before
> making any changes, in my configuration I do not want to add
> administration work on my box that stands between the client and the
> storage.
> Addition is simple, the application on my box can once in a while scan
> the SCSI BUS, and then the Linux system will create new sg devices.
> In removal of a device the Linux system will not remove sg devices after
> scan. In that case again I can do it from my application, such when I
> get attention on SCSI command, I can decide to remove the device by
> echoing to the /sys file system.
I really don't know how the FibreChannel drivers handle device removal.
But from what I gather from the documentation of
fc_remote_port_delete(), which the qla2xxx drivers use, the /dev/sg
devices should automatically disappear
- after a connection loss timeout,
- provided that userspace doesn't have the device file opened
(among else this is manifest in the kernel in a reference count of
the logical unit device representation),
- provided that you manage your device files with udev.
http://lxr.linux.no/linux+v2.6.26/drivers/scsi/scsi_transport_fc.c#L2756
That would be basically just like SCSI device files are created and
destroyed on the fly for USB or FireWire devices for example. Except
that FC has the additional configurable connection loss timeout which
hides temporary connection losses from applications.
(However, better wait for an answer of somebody who actually uses FC or
knows the drivers. I only have experience with FireWire.)
--
Stefan Richter
-=====-==--- -=== =====
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
