Re: lsscsi-0.15 released
Martin Peschke3 wrote: Doug, Providing udev names is great. Makes it more user-frendly. Martin, It can still be tricked: for example putting disk device nodes in a /dev/disks/ directory. Also the udevinfo approach could be tricked by using mknod . Btw., what do you think about this idea: If lsscsi was enhanced to provide certain transport specific attributes, as well, then a user could easily look up the Linux device name of a logical unit that he otherwise knows by its transport specific addressing, like WWPN and so on in case of Fibre Channel. That's desirable, because SAN management is done based on these transport specific addresses. Yes, I did kick around this idea. After discussing some of the complexities, I thought it was better to do an incremental release. One problem is that lsscsi lists the attributes of logical units (i.e. linux SCSI "devices") and hosts (i.e. SCSI initiator ports). However most of the transport information available is bound to SCSI target device ports (and the target device holds one or more logical units). The logical unit may well have transport information but in a bridged environment it is the target's transport that sysfs is reporting. One question is whether to extend lsscsi to cover transports that carry SCSI command sets (e.g. SPI, FC, ATAPI, IEE1394, IB, IP and SAS (to name a few)) or to suggest someone write a lstransport utility. Obviously transports can carry payloads other than SCSI command sets. I guess, this would require to convince James that it makes sense to spend effort on teaching either the midlayer or transport class to keep track of FCP_LUNs, or 64 bit LUNs respectively :) There is probably enough transport information there already in sysfs (but some "back" symlinks would be handy). Increasing the degree of difficulty is the lack of uniformity between transport sysfs representations. The proposed SAS sysfs representation will increase this entropy. I am beginning to see why the (maligned) SDI ioctl interface for SAS HBAs has a tuple to SAS address map. It is the tuple (or subsets of it) that holds lsscsi together. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lsscsi-0.15 released
Doug, Providing udev names is great. Makes it more user-frendly. Btw., what do you think about this idea: If lsscsi was enhanced to provide certain transport specific attributes, as well, then a user could easily look up the Linux device name of a logical unit that he otherwise knows by its transport specific addressing, like WWPN and so on in case of Fibre Channel. That's desirable, because SAN management is done based on these transport specific addresses. I guess, this would require to convince James that it makes sense to spend effort on teaching either the midlayer or transport class to keep track of FCP_LUNs, or 64 bit LUNs respectively :) Martin Peschke |-+> | | Douglas Gilbert | | | <[EMAIL PROTECTED]> | | | Sent by: | | | [EMAIL PROTECTED]| | | .kernel.org | | || | || | | 20/07/2005 10:33 | | | Please respond to| | | dougg| | || |-+> >---| | | | To: linux-scsi@vger.kernel.org | | cc: [EMAIL PROTECTED] | | Subject: lsscsi-0.15 released | | | >---| lsscsi is a utility that uses sysfs in linux 2.6 series kernels to list information about all SCSI devices and SCSI hosts. Both a compact format (default) which is one line per device and a "classic" format (like the output of 'cat /proc/scsi/scsi') are supported. Some examples: $ lsscsi [0:0:0:0]diskLinuxscsi_debug 0004 /dev/sda [1:0:6:0]tapeSONY SDT-7000 0192 /dev/st0 $ lsscsi --classic Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: LinuxModel: scsi_debug Rev: 0004 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 06 Lun: 00 Vendor: SONY Model: SDT-7000 Rev: 0192 Type: Sequential-AccessANSI SCSI revision: 02 Version 0.15 is available at http://www.torque.net/scsi/lsscsi.html This is an experimental version that attempts to find the device name used in the /dev directory rather than the kernel generated name. The kernel generated name of the first SCSI disk discovered is /dev/sda . However in the lk 2.6 series kernels udev may be used to give this device some other name in the /dev directory, for example /dev/root_disk . By default this version will search for the device node name in the /dev directory whose type (i.e. block or char), major and minor numbers match the kernel device information found in sysfs. This change makes a SCSI (or USB, Firewire, etc) CD/DVD drive appear with a name like /dev/scd0 (as most distributions now use) rather than its kernel device node name of sr0 used by sysfs. There are other ways this could be done which would be more efficient in CPU usage, for example by lsscsi using the udevinfo facilities internally. This version of lsscsi can be given a '--kname' option to show the kernel (i.e. sysfs) device node name instead. Note that sysfs and SCSI errors and warning sent to the system log continue to use the kernel device node name. By default lsscsi lists all SCSI devices (or hosts). This version allows select arguments to reduce the number of devices listed. For example "lsscsi 1" will list all channels, targets and luns within host1. A single SCSI device can be listed with 'lsscsi 1 0 0 0' (or 'lsscsi 1:0:0:0' or 'lsscsi [1:0:0:0]'). See man page for more information. This version of lsscsi uses the facilities of the scandir() library call to both select (filter) and sort the SCSI devices (or hosts) it finds in sysfs. Since libsysfs (version 1.2) doesn't have the ability to filter then this version of lsscsi uses scandir() [and not libsysfs]. Evidently a new version 2.0 API for libsysfs is under development (and I have requested a scandir() like select+sort facility). Extra SCSI device and host attributes (as found in lk 2.6.12) can be seen by using the '--long' option twice (or more conveniently using '-ll'). Attributes are listed as "=" pairs, one per line (indented two spaces) whe
