Tape drives and tapes
Tape drive use (for real SCSI tape drives or for emulated tape drives using awstape formats) might be important to some developers. The zPDT system offers a number of options in this area.
SCSI tape drives may be used in two ways:
•The awsscsi device manager allows SCSI tape drives to be used by z System programs.
•Several Linux utilities that directly use SCSI tape drives are provided with zPDT. These utilities may be used when zPDT is not active. These utilities are not associated with devmaps or a device manager.
In general, zPDT supports the use of SCSI tape drives. However, not all SCSI tape drives may be usable. The usability depends on the exact tape drive model, the firmware level, the firmware options selected, and the exact SCSI adapter (and firmware level) that is used. Several different tape drives have been tested, but we cannot guarantee that your tape drive will work. We strongly suggest that you work with your zPDT supplier to understand your SCSI tape drive environment.
This chapter discusses three categories of SCSI tape drives:
•Tape drives using traditional SCSI cables. These are emulated as 3420, 3480, or 3490 drives, regardless of the actual nature of the tape drive.
•IBM 359x tape drives connected with fiber cables that are defined as 3420, 3480, or 3490 drives in the devmap. These are subject to the same comments as when using parallel SCSI cables.
•IBM 359x tape drives connected with fiber cables that are defined as 3590 drives in the devmap.
14.1 The awsscsi device manager
Selected SCSI tape drives may be used as “real” tape drives during zPDT operation. The awsscsi device manager is used and allows the SCSI tape drive to appear as a 3420, 3480, 3490 or 35901 devices.
A typical devmap definition might be as follows:
[manager]
name awsscsi 7000
device 581 3490 3490 /dev/sg5
The 7000 in this example is the arbitrary CUNUMBR operand. This example defines a tape drive at address (device number) 581. If z/OS is being used, then the z/OS IODF must have a corresponding device (IBM 3490) defined for this address. (z/VM detects devices dynamically and would find a 3490 at this address.)
The appearance to software (as a 3490 in the example above) has no direct relation to the actual SCSI device type. In this case, /dev/sg5 might be a DLT drive, for example, that has no physical characteristics of a 3490 drive.2
As shown in Figure 14-1, Linux SCSI devices may be addressed through two interfaces. The relationship between the st and the sg interfaces can be complicated because the sequence number used for a given drive is typically not the same number.
Figure 14-1 SCSI driver interfaces
The Linux device for the SCSI tape drive can be changed with the awsmount command, as in this example:
$ awsmount 580 -u /dev/sg5 (disassociate sg5)
$ awsmount 580 -m /dev/sg3 (mount different drive)
The last operand of the device statement (/dev/sg5 in the example) denotes the SCSI device to be used. Determining this operand is a bit complicated. Linux can address a SCSI tape drive in three ways:
/dev/stN (where Nstarts at 0 and is incremented as needed)
/dev/nstN
/dev/sgN
The /dev/stN and /dev/nstN interfaces are for sequential tape devices. The first tape drive on a Linux system would be /dev/st0; a second tape drive would be /dev/st1, and so forth. The two forms, /dev/stN and /dev/nstN, differ only in whether a rewind is performed when the device is closed.3 The /dev/stN and /dev/nstN interfaces are used with the zPDT stand-alone tape utility functions, such as scsi2tape and tape2scsi, and also by Linux utilities such as tar and mt. The /dev/stN and /dev/nstN interfaces are not used with the awsscsi device manager.
The /dev/sgN devices are general SCSI devices and the awsscsi device manager uses the /dev/sgN interfaces.4 Unfortunately, the N value for a given device is typically not the same in the stN and the sgN forms. All Linux SCSI devices are assigned sgN numbers, and Linux treats many of its normal devices as SCSI (even if they are not really hardware SCSI devices).5 The first (and only) tape drive on a Linux system would be /dev/st0 but it might be /dev/sg7, for example.
Determine st and sg numbers
To manually determine these interfaces, list /proc/scsi/scsi, as in this example:
$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00 (this is sg0)
Vendor: IBM Model: root Rev: V1.0
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00 (this is sg1)
Vendor: IBM Model: 03592E05 Rev: 1C91
Type: Sequential-Access ANSI SCSI revision: 03
This example shows two SCSI devices (a disk and a tape) that correspond to /dev/sg0 and /dev/sg1. In this case, /dev/sg1 is the device you specify for the awsscsi device manager, but any Linux utility uses /dev/st0 or /dev/nst0 for the same tape drive. The devices listed in /proc/scsi/scsi are in sgN order; sg0 is first, sg1 is second, sg2 is third, and so forth.
You can list both the st and sg interface numbers for all SCSI tape drives connected to your system with the aws_findlinuxtape command:
$ aws_findlinuxtape
Vendor: FUJITSU Model: M2488E M2488 Rev: 7 C <===> /dev/st0 /dev/sg10
Vendor: IBM Model: 03592E05 Rev 1C91 <===> /dev/st1 /dev/sg11
Always remember that the sg number can change from one Linux boot to another if there is any configuration change.
Permissions
There is another issue with both /dev/stN and /dev/sgN devices: the permission bits must allow usage by zPDT. Some Linux systems allow general user access to /dev/stN devices by default; no Linux systems allow general access to /dev/sgN devices by default. You must change the permissions to allow general access to your device, as in this example:
$ ls -al /dev/sg*
crw-r----- 1 root disk 21, 0 2008-09-03 14:44 /dev/sg0
crw-rw---- 1 root tape 23, 0,2008-99-03 14:44 /dev/sg1
$ su
(enter root password)
# chmod 666 /dev/sg1
# exit
$ ls -al /dev/sg*
crw-r----- 1 root disk 21, 0 2008-09-03 14:44 /dev/sg0
crw-rw-rw-+1 root tape 23, 0,2008-99-03 14:44 /dev/sg1
In this example, we changed the permissions for /dev/sg1 so that everyone (including zPDT) can read and write to it. This change (by using chmod) is lost when Linux is rebooted, but is suitable for many situations. Always verify the correct sgN number first, by listing /proc/scsi/scsi.
A more permanent change can be made by modifying Linux boot functions. Unfortunately, there are two problems with this:
•The method of modifying Linux boot functions differs with different Linux distributions. For example, we might change /etc/rc.local, or /etc/rc.d/rc.local, or /etc/init.d/boot.local, or another file, depending on the exact Linux distribution.
•We can easily make a general change for stN and nstN devices, but we cannot easily make a general change for sgN devices. We should not change the permissions to allow universal access to all /dev/sgN devices; this would allow easy destruction of our Linux system.
We could place the following lines in /etc/init.d/boot.local (assuming our particular Linux uses this file):
chmod 666 /dev/st[0-9] change all tape devices
chmod 666 /dev/nst[0-9] change all tape devices
chmod 666 /dev/sg7 change particular SCSI device
Do not use chmod 666 /dev/sg[0-9] because this allows anyone to directly access all the SCSI devices in your system. Unless you always have exactly the same devices powered up when you boot Linux, you cannot safely predict the sgN number of a given device.
Block counts
There has been confusion about zPDT use of SCSI-attached tape drives defined as 3490 devices. This definition means the actual device controls and sense information are transformed (by the awstape device manager) to appear as a 3490.
IBM 3490 tape drives provide a block counter. This counter is 22 bits; the largest count it can hold is approximately 4 million. If you write to a SCSI-attached tape drive defined as a 3490 (under zPDT) you will receive an end-of-media indication after writing approximately 4 million blocks. At this point z/OS performs EOV functions and calls for a new tape cartridge (depending on your JCL, of course). The remaining tape media in the first cartridge is not used, but the system works correctly otherwise.
This situation is likely to arise only when using a SCSI 359x tape drive that is defined as a 3490 unit in the devmap. If you read a cartridge written by another system (that was not emulating a 3490 drive) the cartridge might contain more than 4 million blocks. This should work correctly provided the zPDT z System program does not read the block count. If it does, and if the tape position is past the 4 million block point, the z Systems program will indicate a block count error. What happens at that point depends on the design of the particular application program. A tape cartridge with more than approximately 4 million blocks is not fully compatible with 3490 emulation.
14.2 Parallel SCSI adapters
The more recent IBM x System servers (at the time of writing) do not list parallel SCSI adapters for their standard configurations. We understand this to the following meaning:
•IBM did not formally test any of the existing SCSI adapters with these servers.
•There is no known reason why they should not work if the appropriate adapter slots are available.
•We have informally used the Ultra SCSI 320 series of adapters with xServer 3650 M2 and 3500 M2 machines without problems with our older SCSI tape drives.
For some of our systems, we used openSUSE 11.2 or later for this operation. Other and earlier distributions, with Linux kernels below the level used in openSUSE 11.2, did not work with these SCSI adapters on some of our systems. This condition is likely to change with future Linux distributions. If parallel SCSI operation is important to you, we strongly suggest that you discuss your zPDT configuration with your zPDT provider.
•There is no defined IBM support for these configurations.
•Parallel SCSI adapters, cables, and devices can be complex. There are different data path widths, single-ended and differential circuits, low-voltage and high-voltage versions, and a variety of terminators. If you are not familiar with this area, we strongly suggest you obtain expert help in configuring your system.
•The newest SCSI devices use fiber connections instead of parallel (wire) connections.
14.2.1 Specific hardware tested
|
Tip: Be aware that older SCSI drives might require interfaces that are not available with current servers. For example, some older drives require SCSI Fast/Wide High-Voltage Differential adapters. The last generation of these adapters used PCI (not PCIe) adapter slots in servers but many current servers no longer have these slots. The details involved in SCSI tape drive usage can be complex. We strongly suggest that you talk with a knowledgeable zPDT provider about your SCSI tape drive requirements.
|
IBM testing involved the following SCSI drives:
•IBM 3592-E05 TS1120 fibre channel attached SCSI tape drive. The drive was at firmware level 1C91, as determined by the itdtinst1.2LinuxX86 and itdtinst4.1.0.026LinuxX86_64 tools from IBM.
•Fujitsu M2488E parallel SCSI tape drives, with media cartridges compatible with IBM 3480 and 3490 drives. These drives were at firmware level 7.C.01 or 7.xG.01 as determined through the drives control panel.
•IBM LTO-3 3580 parallel SCSI tape drive. This was at firmware level 5BG4 as determined by the itdtinst1.2LinuxX86 tool from IBM.
These drives were tested with IBM System x servers x3650-M1 (7979), x3650-M2 (7947), and x3500-M2 (7939). The following adapters were used:
•Emulex Corporation Zephyr-X LightPulse Fibre Channel Host Adapter (rev 02). This was at Emulex LightPulse x86 BIOS Version 1.71A0, firmware ZS2.50A, as displayed during the BIOS startup.
The Linux device drivers (provided in the Linux distribution) were determined by using the command dmesg | grep Emulex:
– RHEL 5.3 (64-bits): Emulex LightPluse Fibre Channel SCSI driver 8.2.0.33.3p.
– openSUSE 11.1 (64-bits): Emulex LightPluse Fibre Channel SCSI driver 8.2.8.7.
– SLES 11 (64-bits): Emulex LightPluse Fibre Channel SCSI driver 8.2.8.14.
•Q Logic Corporation ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03). This was at BIOS revision 1.28, as displayed during BIOS startup. The firmware level was 4.04.05 [IP][Multi-ID][84XX] as determined by the ql-hba-snapshot.sh tool from Qlogic.
The Linux device drivers (provided in the Linux distribution) were determined by using the command dmesg | grep Qlogic:
– RHEL 5.3 (64-bits): Qlogic Fibre Channel HBA Driver 8.02.00.06.05.03-k.
– openSUSE 11.1 (64.bits): Qlogic Fibre Channel HBA Driver 8.02.01.02.11.0-k9.
•Adaptec ASC-29320ALP U320 (rev 10) parallel SCSI adapter, at Adaptec SCSI Card 29320LPE Flash BIOS v4.31.2S1, as displayed during BIOS startup.
Block size
You probably want to use variable block sizes with SCSI tape drives. You can check for this with these commands:
$ su (switch to root; may not be necessary)
# mt -f/dev/st0 status
If the indicated tape block size is 0 bytes, the drive is set for variable block sizes. If not, enter the following command:
# mt -f/dev/st0 setblk 0
Notice that we use the /dev/stN devices rather than the /dev/sgN devices for these commands. Also, note the Linux must have the mt command installed.
With our older drives and adapters the Linux drivers for Emulex and Qlogic both defaulted to a maximum block size of 32K. Block sizes larger than 32 K are typically not used by application programs; however, large block sizes may be used by backup programs (such as ADRDSSU for z/OS) or by virtual tape managers. (The newer drivers used with the IBM 359x drives defaulted to 64K maximum block size.)
The following Linux commands were used to set def_reserved_size to 65536:
$ su (change to root)
# rmmod sg (removes the sg module)
# /sbin/modprobe sg def_reserved_size=65536
(loads the sg module with the default reserved size up to 64k)
# cat /proc/scsi/sg/def_reserved_size
(displays the current setting for def_reserved_size)
# exit (leave root)
This change allowed both cards to use 64KB reserved buffer size for data transfers. Note that these commands do not make a permanent change. A Linux reboot puts the default size back to 32768.
Recent Linux releases may have changed these interfaces.
14.3 zPDT 359x Tape Support
ITC6 has worked with zPDT development by testing changes to the awsscsi device manager that are designed to more fully support FCP attached IBM 3590/3592 tape units. Although these devices could be physically attached to a zPDT system prior to these awsscsi enhancements, they functioned only in a rather basic mode, emulating a 3490 device. The updated support allows these units to operate in full 359x mode, with minor exceptions.7
All tests were run using openSUSE 12.2 and the Xfce user interface/desktop. The base zPDT system was driver 45.18 and the AWSSCSI modifications were applied on top of that release. Other versions or flavors of Linux were not tested and results may be unpredictable.
14.3.1 The FCP Adapters
ITC has tested several FCP adapters, from both Emulex and Qlogic, including older 2 Mb adapters such as the Emulex LPe1150-E, up to the current FCP adapters offered with IBM System x, such as the 8Mb Emulex, IBM part number 42D0485. Although most testing was with Emulex adapters because they seemed more available, we did test with at least one Qlogic adapter (Dual port, 8 Mb IBM part number 42D0510). In all cases, the FCP driver included in openSUSE 12.2 functioned correctly and newer/different drivers were unnecessary.8 Firmware-related issues, even on the oldest adapters, did not occur so the firmware levels of the various adapters are not documented here. All adapters tested were PCIe format adapters.
14.3.2 3590/3592 Tape drives
Testing was performed with 3592-J1A and 3592-E05 tape units, and the 3590-H11 with 10-cartridge autoloader.9 There are no configuration options for 3590 devices. These drives are also known as TS1120 models.
All 3592 drives need to be configured10 for RACK installation; not for LIBRARY installation. Each drive has two ports. The port you intend to use must be configured as PORT SPEED=Auto Negotiate, TOPOLOGY=L-Port; HARD ADDRESS is suggested to be set to x88 although not required.
Performance is limited by the x86 architecture of the underlying hardware platform and the configuration of the Linux operating system. Consequently, performance numbers cannot be expressed in meaningful terms. Experience has shown that, generally, the performance is acceptable for development users, and allows fully compatible interchange of media with other mainframe data centers.
|
Important: Although you might have a 3592 physical SCSI drive, it should be defined as a 3590 in the devmap in order to match a z/OS IODF entry, as in this example,
device 590 3590 3590 /dev/sg3
|
14.4 zPDT SCSI utilities
Two zPDT utilities can work directly with SCSI tape drives, assuming the Linux system has access to the SCSI adapter. Standard awstape-format files (in Linux) can be moved to and from SCSI tape devices using the scsi2tape and tape2scsi commands.
$ scsi2tape /dev/st0 /z/my/TAPE23 (copy SCSI tape to awstape file)
$ tape2scsi /my/tapes/111111 /dev/st0 (write SCSI tape from awstape file)
$ scsi2tape -c /dev/st0 /z/mytape2 (compress the awstape file)
These two commands are typically used when zPDT is not active.11
14.5 Linux SCSI tape utilities
Linux can provide basic tape utility functions through the mt package. This package is not required for zPDT, but may be useful in other ways. The package is not normally installed by default. In some cases the mt function is part of the cpio function. You might need some detective work to find it.
14.5.1 awstape utilities
zPDT users often build a substantial “tape” library on disk, all in awstape format. The tapeCheck command can be used to verify that a file (which corresponds to a tape volume) is in the correct awstape format.
$ tapeCheck /z/TAPE01 (verify format of awstape file)
The tape2file command copies an awstape file to a simple byte stream in a Linux file, removing the awstape control blocks within the file.
$ tape2file /z/mytape /tmp/filex
The card2tape command copies a Linux text file (in ASCII or EBCDIC) to an awstape file as 80-byte records, using the same conversion conventions as the awsrdr device manager:
$ card2tape /tmp/myLinux.stuff /z/tape01 (copy without translation)
$ card2tape -a /tmp/myLinux.xyz /z/tape01 (force translate ASCII to EBCDIC)
The tape2tape command copies an emulated tape volume (an awstape file in Linux) to another emulated tape volume (another awstape file in Linux):
$ tape2tape /tmp/old.tape /z/new.tape
$ tape2tape -i -s /tmp/old.tape (scan and summarize tape content)
$ tape2tape -c /tmp/old.tape /mine/new.tape (copy and compress)
The -s flag (scan flag) prevents creation of an output file. The -i flag displays a summary of the contents of the input tape. This command is normally used to compress or uncompress an awstape volume or to scan the content. A simple copy of an emulated tape volume (without any additional processing) is easily done with the Linux cp command.
The tapePrint command lists the contents of an emulated tape volume. Data is displayed in hex and character format. The characters are assumed to be EBCDIC unless the -a flag is used:
$ tapePrint /tmp/my.awstape.file
$ tapePrint -a /tmp/my.awstape.file | more
Both the card2tape and tape2tape commands can produce compressed awstape files.
14.6 Practical advice
Most SCSI tape drives do not use vacuum columns to help manage tape start/stop times. Instead they use slower mechanical methods to manage physical tape movement, which means that starting and stopping the tape cannot be done in typical “tape gap” intervals.
For older types of drives the net effect is usually this:
•If the program (including the operating system elements) issues tape read or write commands quickly enough, the tape drive will run the tape at full speed.
•If the program (including the operating system elements) does not issue reads or writes quickly enough, the tape drive will stop after the current data block. The next read or write might cause the tape drive to “backhitch” (that is, back up the tape for a distance) and then restart forward movement. This is done to ensure the tape is “up to speed” for the next read or write operation.
This backhitch movement can greatly reduce the effective data speed of the drive. Not all drives encounter this; other factors such as internal buffering on newer types of drives can help avoid it. You can typically hear the effects of a tape drive doing a backhitch for every data block.
If you encounter this situation, an alternative approach is to use the zPDT SCSI utilities, such as scsi2tape, to copy the SCSI tape to an awstape emulated tape volume. The SCSI utilities are fast and should not encounter any backhitching. Your application could then process the emulated tape volume copy instead of the real SCSI tape volume. This might result in much faster processing of your tape data.
The SCSI adapters needed to use older SCSI tape drives might not be compatible with newer servers. One solution is to acquire an older server with appropriate adapters and use it to convert older tapes into awstape format files. This format can be readily moved to newer servers running zPDT.
1 Usage as a 3590 drive requires a fibre adapter and a “real” 359x drive.
2 IBM did not formally test DLT drives.
3 The /dev/stN device automatically rewinds (whatever this might mean for the actual device) when the device is closed. The /dev/nstN devices do not provide an automatic rewind.
4 The reason is that the /dev/stN interface does not accept the full SCSI command set that is necessary for some tape operations. The /dev/sgN interface allows all SCSI tape commands to be passed to the tape drive.
5 The sg numbers are assigned in ascending order by bus and by device on the bus. However, since Linux treats a number of non-SCSI devices as though they were SCSI, these bus and device numbers are difficult to predict in advance.
6 Information Technology Company LLC, 7389 Lee Highway, Falls Church, VA 22042 or [email protected].
7 One exception is that automated tape library functions are not supported.
8 This may not be true for other/older Linux distributions or for FCP adapters that are not so widely used.
9 ITC also has available single and dual drive models (E05, E06, and E07) that are complete ready-to-run units with power supplies, IBM FICON® adapter, FICON cable, CE-Panel, and warranty.
10 Configuration changes are entered through an optional CE panel. The drives obtained by the zPDT developers did not require configuration changes. You might discuss the need for a CE panel with your 359x provider.
11 If the SCSI devices are not in the active devmap, these utilities can be safely used while zPDT is active.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.