Linux SCSI subsystem

The first problem when working with SCSI devices might be to map information you got from /proc/scsi/scsi to the device names the kernel uses like /dev/sda and so on.

The answer is to use lsscsi utility. In both RHEL and SLES lsscsi utility in installed by default. Here's an example:

# lsscsi -l
basfimgw:/etc/sysconfig # lsscsi -l
[2:0:0:0]    cd/dvd  TEAC     DV-W28S-VS       G.V0  /dev/sr0
  state=running queue_depth=1 scsi_level=6 type=5 device_blocked=0 timeout=30
[4:0:0:0]    disk    IBM      2145             0000  /dev/sda
  state=running queue_depth=32 scsi_level=5 type=0 device_blocked=0 timeout=60
[4:0:1:0]    disk    IBM      2145             0000  /dev/sdb
  state=running queue_depth=32 scsi_level=5 type=0 device_blocked=0 timeout=60
[5:0:0:0]    disk    IBM      2145             0000  /dev/sdc
  state=running queue_depth=32 scsi_level=5 type=0 device_blocked=0 timeout=60
[5:0:1:0]    disk    IBM      2145             0000  /dev/sdd
  state=running queue_depth=32 scsi_level=5 type=0 device_blocked=0 timeout=60

The second place place to look is /proc/scsi/scsi. For example:

# cat /proc/scsi/scsi
Attached devices:
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: TEAC Model: DV-W28S-VS Rev: G.V0
Type: CD-ROM ANSI SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: 2145 Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04
Host: scsi4 Channel: 00 Id: 01 Lun: 00
Vendor: IBM Model: 2145 Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04
Host: scsi5 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: 2145 Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04
Host: scsi5 Channel: 00 Id: 01 Lun: 00
Vendor: IBM Model: 2145 Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04  

The first line of each device contains SCSI-ID of the device in the form

Host: scsi1 Channel: 00 Id: 03 Lun: 00

which means 1:0:3:0 in traditional notation.

The question arise what is the name of this device. It is visible in lsscsi listing, but also can be gotten from /sys/bus/scsi/drivers/sd/<SCSI-ID> subdirectory.

For example for device 5:0:0:0 we can see

/sys/bus/scsi/drivers/sd/5:0:0:0 # ll
total 0
lrwxrwxrwx 1 root root    0 Aug 30 17:09 block:sdg -> ../../../../../../../../../../block/sdg
lrwxrwxrwx 1 root root    0 Aug 30 17:09 bus -> ../../../../../../../../../../bus/scsi
--w------- 1 root root 4096 Aug 30 17:09 delete
-r--r--r-- 1 root root 4096 Aug 30 17:09 device_blocked
-rw-r--r-- 1 root root 4096 Aug 30 17:09 dh_state
lrwxrwxrwx 1 root root    0 Aug 30 17:09 driver -> ../../../../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root    0 Aug 30 17:09 generic -> ../../../../../../../../../../class/scsi_generic/sg9
-r--r--r-- 1 root root 4096 Aug 30 17:09 iocounterbits
-r--r--r-- 1 root root 4096 Aug 30 17:09 iodone_cnt
-r--r--r-- 1 root root 4096 Aug 30 17:09 ioerr_cnt
-r--r--r-- 1 root root 4096 Aug 30 17:09 iorequest_cnt
-rw-r--r-- 1 root root 4096 Aug 30 17:09 max_sectors
-r--r--r-- 1 root root 4096 Aug 30 17:09 model
drwxr-xr-x 2 root root    0 Aug 30 17:09 power
-r--r--r-- 1 root root 4096 Aug 30 17:09 queue_depth
-r--r--r-- 1 root root 4096 Aug 30 17:09 queue_type
--w------- 1 root root 4096 Aug 30 17:09 rescan
-rw-r--r-- 1 root root 4096 Aug 30 17:09 retries
-r--r--r-- 1 root root 4096 Aug 30 17:09 rev
lrwxrwxrwx 1 root root    0 Aug 30 17:09 scsi_device:5:0:0:0 -> ../../../../../../../../../../class/scsi_device/5:0:0:0
lrwxrwxrwx 1 root root    0 Aug 30 17:09 scsi_disk:5:0:0:0 -> ../../../../../../../../../../class/scsi_disk/5:0:0:0
lrwxrwxrwx 1 root root    0 Aug 30 17:09 scsi_generic:sg9 -> ../../../../../../../../../../class/scsi_generic/sg9
-r--r--r-- 1 root root 4096 Aug 30 17:09 scsi_level
-rw-r--r-- 1 root root 4096 Aug 30 17:09 state
-rw-r--r-- 1 root root    0 Aug 30 17:09 timeout
-r--r--r-- 1 root root 4096 Aug 30 17:09 tpgs
-r--r--r-- 1 root root 4096 Aug 30 17:09 type
--w------- 1 root root 4096 Aug 30 17:09 uevent
-r--r--r-- 1 root root 4096 Aug 30 17:09 vendor

It is now clear this device is known to the kernel as sdg.

Note: the example above is from Novell's SuSE 11 SP 1 Enterprise Linus but works with Red Hat as well.

Rescanning of a SCSI bus

Let's assume you've added a SCSI disk to a SCSI bus (either a physical or virtual device). One possibility to make it known to the system would be to reboot the server. But you can rescan SCSI bus instead.

You can use /usr/bin/rescan-scsi-bus.sh script (exists both in RHEL as /usr/bin/rescan-scsi-bus.sh and in Suse as /bin/rescan-scsi-bus.sh ).

/bin/rescan-scsi-bus.sh 
Host adapter 0 (megaraid_sas) found.
Host adapter 1 (mptspi) found.
Host adapter 2 (qla2xxx) found.
Host adapter 3 (qla2xxx) found.
Host adapter 4 (usb-storage) found.
Host adapter 5 (usb-storage) found.

Scanning SCSI subsystem for new devices
Scanning host help for  SCSI target IDs  0 1 2 3 4 5 6 7, all LUNs
0 new device(s) found.
0 device(s) removed.

Here is a help for the script:

/bin/rescan-scsi-bus.sh --help
Usage: rescan-scsi-bus.sh [options] [host [host ...]]
Options:
 -l      activates scanning for LUNs 0--7   [default: 0]
 -L NUM  activates scanning for LUNs 0--NUM [default: 0]
 -w      scan for target device IDs 0--15   [default: 0--7]
 -c      enables scanning of channels 0 1   [default: 0 / all detected ones]
 -r      enables removing of devices        [default: disabled]
 -i      issue a FibreChannel LIP reset     [default: disabled]
--remove:        same as -r
--issue-lip:     same as -i
--forcerescan:   Rescan existing devices
--forceremove:   Remove and readd every device (DANGEROUS)
--nooptscan:     don't stop looking for LUNs is 0 is not found
--color:         use coloured prefixes OLD/NEW/DEL
--hosts=LIST:    Scan only host(s) in LIST
--channels=LIST: Scan only channel(s) in LIST
--ids=LIST:      Scan only target ID(s) in LIST
--luns=LIST:     Scan only lun(s) in LIST
--sync/nosync:   Issue a sync / no sync [default: sync if remove]
--attachpq3:     Tell kernel to attach sg to LUN 0 that reports PQ=3
--reportlun2:    Tell kernel to try REPORT_LUN even on SCSI2 devices
--largelun:      Tell kernel to support LUNs > 7 even on SCSI2 devs
--sparselun:     Tell kernel to support sparse LUN numbering
 Host numbers may thus be specified either directly on cmd line (deprecated) or
 or with the --hosts=LIST parameter (recommended).
LIST: A[-B][,C[-D]]... is a comma separated list of single values and ranges

The other way to issue a SCSI bus rescan is to type echo "- - -" > /sys/class/scsi_host/hostX/scan where X stands for the SCSI host you want to scan (0,1,2,...):

/sys/class/scsi_host # ll
total 0
drwxr-xr-x 2 root root 0 Sep 19 13:11 host0
drwxr-xr-x 2 root root 0 Sep 19 13:11 host1
drwxr-xr-x 2 root root 0 Sep 19 13:11 host2
drwxr-xr-x 2 root root 0 Sep 19 13:11 host3
drwxr-xr-x 2 root root 0 Sep 19 13:11 host4
drwxr-xr-x 2 root root 0 Sep 19 13:11 host5

This also works for SCSI CD/DVD devices.

Note: a rescan of the SCSI bus will only detect new devices added to the bus. It will not detect the state of an already known device - e.g. if it's failed or online.

Deletion of a SCSI Device

to remove a SCSI device from the system you can use

echo 1 > /sys/bus/scsi/drivers/sd/<SCSI-ID>/delete.

Note: To add the device back, simply rescan the whole SCSI bus. Adding the device will change the device names - i.e. by deleting /dev/sde and readding it using the scsi bus rescan it will become dev/sdf

Rescan of a SCSI Device

The problem of a SCSI bus rescan is, that it will only detect new devices. To rescan existing device which might be switched on, use the command

echo 1 > /sys/bus/scsi/drivers/sd/<SCSI-ID>/block/device/rescan

For example

cd /sys/bus/scsi/drivers/sd/0:0:1:0/block/device 

# echo 1 > rescan

# tail -f /var/log/messages
...

As you will see the rescan has told the kernel that the device is up and running.

NEWS CONTENTS

• : How do I rescan the SCSI bus to add or remove a SCSI device without rebooting the computer ( Red Hat Knowledgebase )
• : How do I rescan an HP Smart Array for new disks without rebooting in Red Hat Enterprise Linux 4? ( IBM )

Old News ;-)

How do I rescan the SCSI bus to add or remove a SCSI device without rebooting the computer

Red Hat Knowledgebase

It is possible to add, remove, or re-size a SCSI device without rebooting a running system. If this is done explicitly, one device at a time, then it is not necessary to stop all I/O to other storage devices on the system. If this is done by resetting or re-scanning an entire SCSI bus, then all storage I/O must be stopped and flushed before performing these operations.

This article is a brief summary of the information contained in the Online Storage Reconfiguration Guide. Refer to that document fo complete coverage of this topic.

Environment

Technical support for online storage reconfiguration is only provided on Red Hat Enterprise Linux 5. Limited tools for hot adding and removing storage are present in previous releases of Red Hat Enterprise Linux however they cannot be guaranteed to work correctly in all configurations. Red Hat Enterprise Linux 5 includes many enhancements to udev, the low level device drivers, SCSI midlayer, and device-mapper multipath which enables comprehensive support for online storage reconfiguration.

This article, and the Online Storage Reconfiguration Guide, currently cover the FC and iSCSI transports. Future versions of this documentation will cover other SCSI transports, such as SAS and FCoE.

Resolution

Removing a Storage Device

Before removing access to the storage device itself, you may want to copy data from the device. When that is done, then you must stop and flush all I/O, and remove all operating system references to the device, as described below. If this is a multipath device then you must do this for the multipath psuedo device, and each of the identifiers that represent a path to the device.

Removal of a storage device is not recommended when the system is under memory pressure, since the I/O flush will add to the load. To determine the level of memory pressure run the command:

vmstat 1 100

Device removal is not recommended if swapping is active (non-zero "si" and "so" columns in the vmstat output), and free memory is less than 5% of the total memory in more than 10 samples per 100. (The total memory can be obtained with the "free" command.)

The general procedure for removing all access to a device is as follows:

1. Close all users of the device. Copy data from the device, as needed.

2. Use umount to unmount any file systems that mounted the device.

3. Remove the device from any md and LVM volume that is using it. If the device is a member of an LVM Volume group, then it may be necessary to move data off the device using the pvmove command, then use the vgreduce command to remove the physical volume, and (optionally) pvremove to remove the LVM metadata from the disk.

4. If you are removing a multipath device, run multipath -l and take note of all the paths to the device. When this has been done, remove the multipath device:

multipath  -f device

5. Use the following command to flush any outstanding I/O to all paths to the device:

blockdev -flushbufs device

This is particularly important for raw devices, where there is no umount or vgreduce operation to cause an I/O flush.

6. Remove any reference to the device's path-based name, like /dev/sd or /dev/disk/by-path or the major:minor number, in applications, scripts, or utilities on the system. This is important to ensure that a different device, when added in the future, will not be mistaken for the current device.

7. The final step is to remove each path to the device from the SCSI subsystem. The command to remove a path is:

echo 1 >  /sys/block/device-name/device/delete

Where device-name may be sde, for example.

Another variation of this operation is:

echo 1 >  /sys/class/scsi_device/h:c:t:l/device/delete

Where h is the HBA number, c is the channel on the HBA, t is the SCSI target ID, and l is the LUN.

You can determine the device-name and the h,c,t,l for a device from various commands, such as lsscsi, scsi_id, multipath -l, and ls -l /dev/disk/by-*

If each of the steps above are followed, then a device can safely be removed from a running system. It is not necessary to stop I/O to other devices while this is done.

Other procedures, such as the physical removal of the device, followed by a rescan of the SCSI bus using rescan-scsi-bus or issue_lip to cause the operating system state to be updated to reflect the change, are not recommended. This will cause delays due to I/O timeouts, and devices may be removed unexpectedly. If it is necessary to perform a rescan of an interconnect, it must be done while I/O is paused. Refer to the Online Storage Reconfiguration Guide.

Adding a Storage Device or a Path

When adding a device, be aware that the path-based device name (the "sd" name, the major:minor number, and /dev/disk/by-path name, for example) that the system assigns to the new device may have been previously in use by a device that has since been removed. Ensure that all old references to the path-based device name have been removed. Otherwise the new device may be mistaken for the old device.

The first step is to physically enable access to the new storage device, or a new path to an existing device. This is done with vendor-specific commands at the FC or iSCSI storage server. When you do this, take note of the LUN value for the new storage that will be presented to your host.

Next, make the operating system aware of the new storage device, or path to an existing device. The preferred command is:

echo "c t l" >  /sys/class/scsi_host/hostH/scan

where H is the HBA number, c is the channel on the HBA, t is the SCSI target ID, and l is the LUN.

You can determine the h,c,t by refering to another device that is already configured on the same path as the new device. This can be done with commands such as lsscsi, scsi_id, multipath -l, and ls -l /dev/disk/by-*. This information, plus the LUN number of the new device, can be used as shown above to probe and configure that path to the new device.

After adding all the SCSI paths to the device, execute the multipath command, and check to see that the device has been properly configured. At this point, the device is available to be added to md, LVM, mkfs, or mount, for example.

If the steps above are followed, then a device can safely be added to a running system. It is not necessary to stop I/O to other devices while this is done.

Other procedures, involving a rescan, or a reset, of the SCSI bus to cause the operating system to update its state to reflect the current device connectivity, are not recommended. Refer to the Online Storage Reconfiguration Guide for more information.

Considerations for Virtual Guests

The procedures above also apply to hypervisors (i.e. dom0 in Red Hat Enterprise Linux 5 virtualization), but the procedures are different for dynamically altering the storage of running virtual guests. For more information about adding storage to virtual guests, see the Virtualization Guide.

Note for Hewlett-Packard SmartArray Controllers

Hewlett-Packard SmartArray controllers and other hardware that uses the cciss driver provide a different interface for manipulating SCSI devices. Users of this hardware can find a similar guide here

How do I rescan an HP Smart Array for new disks without rebooting in Red Hat Enterprise Linux 4?

Article ID: 7833 - Created on: Nov 23, 2006 6:00 PM - Last Modified: Nov 26, 2006 6:00 PM

HP Smart Array disks use the cciss driver. If new disks that support hot-swap are added to a running system, they will not be seen by the system until the scsi bus is re-scanned. This normally happens on reboot. If a reboot is not possible or desirable, the following commands can be used. First, a rescan is done to inform the cciss driver about the changes to the SCSI bus:

echo "rescan" > /proc/driver/cciss/cciss0
Then, add an individual device with:

echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi

The above example would add a device on controller 3, bus 2, target 1, lun 0. Change the values according to the position and settings of the device that was added.

Set up SCSI devices

This section covers material for topic 1.101.4 for the Junior Level Administration (LPIC-1) exam 101.

IBM

SCSI overview

The Small Computer System Interface, more generally known as SCSI, is an interface designed for connecting streaming devices such as tapes and block storage devices such as disks, CD-ROMs, and DVDs. It has also been used for other devices, such as scanners and printers. SCSI is pronounced "scuzzy". SCSI was designed to allow multiple devices on the bus. One device, called the controller has responsibility for managing the bus. SCSI devices may be either internal or external.

There have been three major releases of SCSI standards from the American National Standards Institute (ANSI).

• SCSI is the original standard (X3.131-1986), now usually called SCSI-1. This arose from efforts by Shugart Associates to get a standard interface for disk devices. The standard supported up to 8 devices on a cable. SCSI-1 uses passive termination (more on this below). This standard has now been withdrawn, although devices may still work on current SCSI cables assuming appropriate termination. The data interface was 8 bits parallel with a maximum speed of 5 MBps (megabytes/sec). The SCSI standard was designed for disks, but is very flexible and was used for other devices, notably scanners and slower devices such as Zip. FConnection used a 50 connector cable, originally with a Centronics connector, but later with a 50-pin D-shell connector, similar to a DB-25 RS-232 serial connector,
• SCSI-2 was approved as ANSI standard X3.131-1994 in 1994. This revision doubled the speed of the bus to 10MBps as well as introducing so-called wide or 16-bit data transfers. A 16-bit bus running at 10MBps can transfer 20MBps of data. The 50-connector cable was used for 8-bit or narrow SCSI devices, while the newer wide devices used a 68-pin cable. Higher density cables were also introduced, allowing smaller and cheaper connectors. SCSI-2 also standardized the SCSI command set and introduced differential signaling to improve quality at higher speeds. This was later called High Voltage Differential or HVD signaling. HVD has active termination requirements. It is possible to mix 8-bit and 16-bit devices on a cable with appropriate care in termination. SCSI-2 supports up to 16 devices on a cable of which at most 8 may be narrow.
• SCSI-3 is a set of standards rather than a single standard. This allows standards to be enhanced for technology areas that are fast-moving, while avoiding the need to revise standards for stable technology. The overall architecture is defined in ANSI standard X3.270-1996 which is also known as the SCSI-3 Architecture Model or SAM. The earlier SCSI standards are now embodied in the SCSI Parallel Interface or SPI standards. Speed was increased again and current 16-bit devices are capable of up to 320MBps data transfers at a bus speed of 160MBps.

SCSI-3 introduced Fiber Channel SCSI with support for up to 126 devices per bus allowing connection over 1GBps or 2GBps fiber channel links at distances up to several kilometers. This helps to alleviate inherent limitations involved with the use of standard SCSI cabling. Another notable introduction was Single Connector Attachment or SCA which is only used for wide (16-bit) devices. SCA is an 80-pin connector which incorporates the pins from the 68-pin connector as well as power and some additional pins. SCA is designed to allow devices to be safely hot-plugged in a running system, and is frequently used in devices implementing Redundant Array of Independent disks or RAID storage systems as well as network attached storage and server racks.

We mentioned termination above without saying much about it. The electrical specifications for a SCSI bus require each end of the bus to be properly terminated. You must use the appropriate type of terminator for your bus; passive, HVD or LVD. If you mix wide and narrow devices on a bus be aware that the termination for narrow devices may occur in a different place to the termination for wide devices. If the controller is controlling only an internal bus or only an external bus, it will usually provide termination, either automatically or via BIOS configuration. Check the manuals for your particular controller. If the controller is controlling both an internal and an external segment, then it should normally not provide termination.

Some devices are capable of providing termination, either via a switch, or other means such as a jumper. Again, consult the manual for your device. Otherwise, termination is usually accomplished with a terminator block which is plugged into the cable. Whichever type of termination you use, be particularly careful if you mix wide and narrow devices on the same bus, as the narrow termination may occur at a different place on the cable than the wide termination.

SCSI Ids

By now, you may be wondering how the system manages many devices on one cable. Every device, including the controller, has an ID, represented by a number. For narrow (8-bit) SCSI, the ID numbers range from 0 through 7. Wide SCSI adds numbers 8 through 15. Narrow devices may only use ID numbers 0 through 7 while wide devices may use 0 through 15. The controller is generally assigned ID 7. The ID for a devices may be set via jumpers, switches or dials on the device, or through software. Devices using the Single Connector Attachment (SCA) usually have an ID assigned automatically as these devices may be hot-plugged.

Devices on a SCSI bus have a priority. Priority for narrow devices runs from 0 (lowest) through 7 (highest), so a controller at address 7 has highest priority. The extra IDS for wide SCSI have priority 8 (lowest) through 15) highest, with 15 having lower priority than 0. Thus, the overall priority sequence is 8, 9, 10, 11, 12, 13, 14, 15, 0, 1, 2, 3, 4, 5, 6, 7. Slower devices and devices that cannot tolerate delays (such as CD or DVD recorders) should be given high priority IDs to ensure they get sufficient service.

Devices such as RAID controllers may present a single ID to the bus but may incorporate several disks. In addition to the ID, the SCSI addressing allows a Logical Unit Number or LUN. Tapes and single disk drives either do not report a LUN or report an LUN of 0.

A SCSI adapter may support more than one SCSI cable or channel, and there may be multiple SCSI adapters in a system. The full ID of a device therefore consists of an adapter number, a channel number, a device ID and a LUN.

Devices such as CD recorders using ide-scsi emulation and USB storage devices will also appear to have their own adapter.

Linux names and files for SCSI devices

Back in the BIOS section on IDE drives we discussed the names assigned by Linux to the various IDE devices, such as /dev/hda and /dev/hdc. This is simple for an IDE controller which can support either one or two hard drives. The secondary IDE drive on the second adapter is always /dev/hdd, even if the only other hard drive is the primary drive on the first adapter (/dev/hda). With SCSI the situation becomes more complicated as we may mix hard drives, tapes, CD and DVD drives, as well as other devices on a SCSI cable.

Linux will assign device names as devices are detected during boot. Thus, the first hard drive on the first channel of the first adapter will become /dev/sda, the second /dev/sdb, and so on. The first tape drive will be /dev/st0, the second /dev/st1, and so on. The first CD device will become /dev/sr0 or /dev/scd0 and the second /dev/sr1 or /dev/scd1. Devices using SCSI emulation, such as USB storage devices and (prior to the 2.6 kernel) IDE CD or DVD drives will also be allocated names in this name space.

While we won't cover all the intricacies of SCSI naming here, it is most important to know that this numbering is redone at each boot. If you add or remove a SCSI hard drive, then all previously higher drives will have a different device name next time you boot. The same goes for other device types. We will learn more about partitions, labels and file systems in another tutorial in this series, but for now we will warn you about one thing. Since disks can have up to 15 partitions on them, each with a name tied to the device name (for example, /dev/sda1, /dev/sda2 through /dev/sda15), this can cause havoc when your system attempts to mount the filesystems. Plan very carefully when you add or remove SCSI devices and use disk labels rather than device names for SCSI disks whenever possible.

We introduced the /proc file system in the section on BIOS settings. The /proc file system also contains information about SCSI devices. Listing 19 shows the contents of /proc/scsi/scsi on a system with two SCSI devices, a hard drive with ID 0 and a controller with ID 8.

Listing 19. /proc/scsi/scsi

                    
[root@waratah root]# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM-PSG  Model: DPSS-336950M  F  Rev: S94S
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 08 Lun: 00
  Vendor: IBM      Model: YGLv3 S2         Rev: 0
  Type:   Processor                        ANSI SCSI revision: 02

If you want to know which real device corresponds to say /dev/sda, you can use the scsi_info command. Listing 20 confirms that our first (and only) SCSI hard drive is /dev/sda.

Listing 20. The scsi_info command

                    
[root@waratah root]# scsi_info /dev/sda
SCSI_ID="0,0,0"
MODEL="IBM-PSG DPSS-336950M  F"
FW_REV="S94S"

However, note that some systems, such as Fedora Core 2, do not include the scsi_info command (which is a part of the kernel-pcmcia-cs package).

More recent systems have switched to using the SCSI Generic or sg driver. When the sg driver is used, you will find additional information under the /proc/scsi/sg subtree in your filesystem. You will also have devices such as /dev/sg0, /dev/sg1. /dev/sg2 and so on. These generic devices usually correspond to some other device type such as a hard disk like /dev/sda or a tape like /dev/st0.

The sg3_utils package contains a number of utilities for manipulating and interrogating aspects of the SCSI subsystem. In particular, the sg_map command will provide a map between the sg name and another device name if one exists. Note that scanners will not have another device name, only a generic one. Listing 21 shows the output of sg_map on a system with an IDE optical drive that uses SCSI emulation and two USB drives.

Listing 21. The sg_map command

                    
[root@lyrebird root]# sg_map
/dev/sg0  /dev/scd0
/dev/sg1  /dev/sda
/dev/sg2  /dev/sdb

The sg utility corresponding to scsi_info is sginfo. You can use either the generic device name or the more familiar name with sginfo. Listing 22 shows the output of sginfo for the three devices of Listing 21. Notice that sginfo does not provide information for /dev/sg1, although as shown in the listing the scsi_info command does show it as a USB memory key. In this case, the device has been unplugged from the system. Information about it is retained (and can be found in /proc/scsi/scsi). the sginfo command interrogates the device for the information while the scsi_info will use the retained information. Thus sginfo must be run as root while scsi_info need not be run as root, although non root users may have to specify the full path of /sbin/scsi_info.

Listing 22. The sginfo command

                    
[root@lyrebird root]# sginfo /dev/scd0
INQUIRY response (cmd: 0x12)
---------------------------
Device Type                        5
Vendor:                    SONY
Product:                   DVD RW DRU-700A
Revision level:            VY08

[root@lyrebird root]# sginfo /dev/sg1
INQUIRY reponse (cmd: 0x12)
---------------------------
Device Type                        0
Vendor:
Product:
Revision level:

[root@lyrebird root]# sginfo /dev/sg2
INQUIRY reponse (cmd: 0x12)
---------------------------
Device Type                        0
Vendor:                    WD
Product:                   2500JB External
Revision level:            0411

[root@lyrebird root]# scsi_info /dev/sg1
SCSI_ID="0,0,0"
MODEL=" USB DISK 12X"
FW_REV="2.00"

SCSI BIOS and boot sequence

While SCSI is standard on most servers, most desktop and laptop computers do not normally include SCSI support as standard. Such systems will normally boot from a floppy disk, a CD or DVD drive or the first IDE hard drive in the system. The boot order is usually configurable in BIOS setup screens such as we saw in the section BIOS settings, and sometimes dynamically by pressing a key or key combination during system startup.

The BIOS Boot Specification (see Resources) defines a method for add on cards such as SCSI cards to present a message during startup and have BIOS on the card invoked for configuration purposes. SCSI cards normally use this to allow configuration of the SCSI subsystem controlled by the card. For example, an Adaptec AHA-2930U2 card will present a message

Press <Ctrl><A> for SCSISelect (TM) Utility!

allowing a user to press the ctrl and A keys together to enter the adapter BIOS. Other cards will have a similar process for entering the card BIOS to set up the card.

Once in the card BIOS, you will have screens that typically allow you to set the SCSI controller address (typically 7), the SCSI boot device (usually ID 0), the bus speed and whether the controller should provide termination or not. Some older cards may require that the boot device be ID 0, but most modern cards will allow you to choose any device. You may, and probably will, have other options, such as the ability to format a hard disk. See your card manufacturer's documentation for details. Once you have set up the SCSI view of the bus, you will usually still have to tell your PC BIOS to boot from the SCSI disk rather than an IDE drive. Consult your system reference manual to determine whether you can boot from a non-IDE drive and how to set it if you can.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Anatomy of the Linux SCSI subsystem

• Check out the Technical Committee T10 to learn more about the various SCSI specifications, from the fundamental commands of SCSI to the newest SCSI protocols like SAS.

• This article from the Open Source Development Lab focuses on the 2.6 kernel and the SCSI disk driver for a detailed look at the SCSI implementation in the Linux kernel.

• This list of user-space tools to query, view, or manage SCSI devices makes use of the SCSI generic driver in the Linux kernel. (Linux supports a number of SCSI tools, including the sg3utils mentioned in this article.)

• "Anatomy of the Linux kernel" (developerWorks, June 2007) gives a general overview of the Linux kernel and each of its major subsystems.

• "Kernel command using Linux system calls" (developerWorks, March 2007) explores the system call interface within the Linux kernel (from user-space call to kernel completion).

• "Anatomy of the Linux networking stack" (developerWorks, June 2007) introduces the basic architecture of the networking stack in Linux, including the major components and structures that are involved.

• "Anatomy of the Linux file system" (developerWorks, October 2007) explores the virtual file system (VFS)-sometimes called the virtual filesystem switch-in the Linux kernel and then reviews some of the major structures that tie file systems together.

• Fibre Channel over Ethernet (FCoE) is one of the interesting SCSI protocols coming in the future. It is not yet available but is actively under development by a number of vendors.

• Learn more in this white paper on the Data Integrity Field (DIF) technique for end-to-end protection. DIF provides protection on disk, detects misdirected writes, and allows application-specific tags to accompany the data for further protection. DIF is a multi-vendor technology, which means you'll find support for it in drives and HBAs from a variety of vendors.

• lsscsi -- list all SCSI devices

• Anatomy of the Linux SCSI subsystem

• scsi_design_analysis_2_6_v2

• Shell script to rescan Linux SCSI bus using the scsi add-single-device mechanism

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019