Command to Display Tape Density

[Jim Sobiesczyk]

I'm new to HP, but I need to display the Blocking for tape drive.

What's the command to do this? Would IOSCAN give everything I need?

Kinda pressed for time to get some statistics to mgmnt, so your response will be greatly appreciated.

[A. Clay Stephenson]

ioscan will not do the trick.

Bear in mind that most tape drives in HP-UX use variable blocking so that the application itself determines the blocksize; from that standpoint, your question may be meaningless; however, it is possible to create fixed block device node.

cd /dev/rmt
lssf *

lssf will display the available data. You can create fixed-block tape device nodes via the insf command.

Man lssf, insf for details.

[Bill Hassell · Accepted solution]

Tape density (as in bytes per inch) have been obsolete for about two decades. Reel-to-reel (1/2" width) tapes had densities like 200, 555, 800, 1600 and 6250 BPI (bytes per inch), but modern tapes like DDS and DLT use a helical scan method much like video tapes. In this scheme, the recording heads are spun at an angle to the tape, thus creating angled tracks. In addition, the data is heavily encoded into special blocks with error correction and codes for file separators and high speed searchmarks. But the data is always the same density.

Now compression does not change this density. Compression means that repeating patterns can be reduced to less bytes, but the data is still written to the tape at the same density. Modern tape drives are also heavily buffered (many megs) because they are streamers, that is, no start/stop for each record. This makes the physical blocks of data written to the tape completely transparent (as it should be) so the classic concept of tape blocks is unimportant.

More to the point, the application (backup programs, copy commands, etc) defines the length of a record, so blocksize is meaningless for the tape drive. The only really useful spec is the NATIVE capacity of the tape. Unlike old 1/2" tapes where thinner (which are longer) could store more data, DDS, DLT, AIT and other modern tapes are fixed in size for a specific drive. Most drives are backward compatible (ie, a DDS4 drive can read a DDS3 or DDS2 tape) but a DDS4 tape is automatically rejected by a DDS3 tape drive.

Here is a useful table comparing tape drives:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00028345

So there is no blocking for modern tape drives, only programs that write certain size (or variable) records. NOTE: modern tape drives are extremely fast, gobbling up data so fast that it can exceed the speed of slow or busy disks. Many managers will be tempted to buy the largest capacity tape drive thinking that all things are equal. But an Ultrium 460 tape drive needs 30-60 megs per second to keep moving at full speed. Be careful about overbuying a high performance tape drive based on capacity. Older systems with slower disks may never keep pace with the drive and will seriously slow the backup speed as well as increase drive wear.

[Jim Sobiesczyk]

A. Clay Stephenson:

Thanks for your comments and suggestions.

Bill Hassell:

Thanks for the historical info on tape technology. It brought me memories of many years ago! I came from those ancient days of working with 2400 bpi reel tapes/drives! We sure've come a long way!

I work mostly with AIX who still uses Block-Size as one of the options for their tape devices, so you can change it if you receive tapes from outside your environment. They also have the option to use variable length.

I do notice that my subject-line said 'density', but my comments were referring to block-sizes. Sorry for the confusion I made by using them together in my note.

I did notice that when I ran the 'lssf' command, the information on a tape device it still refers to density though. So I guess HP still is using the terminology?

Going forward, your last paragraph will be very useful in any decision-making for disk-to-tape drive performance.

Thanks again.

[A. Clay Stephenson]

Actually, if you create fixed-block device node for a tape device, you can see the blocksize.

Here is an ls -l of /dev/rmt.
crw-rw-rw- 2 bin bin 205 0x050040 Apr 18 2003 1mn
crw-rw-rw- 2 bin bin 205 0x0500c0 Apr 18 2003 1mnb
crw-rw-rw- 2 bin bin 205 0x040000 Apr 8 2005 2m
crw-rw-rw- 2 bin bin 205 0x040080 Apr 18 2003 2mb
crw-rw-rw- 2 bin bin 205 0x040080 Apr 18 2003 2mb
crw-rw-rw- 2 bin bin 205 0x0400c0 Mar 18 2005 2mnb
crw-rw-rw- 2 bin bin 205 0x042000 May 1 2003 3m
crw-rw-rw- 2 bin bin 205 0x042080 May 1 2003 3mb
crw-rw-rw- 2 bin bin 205 0x042040 May 1 2003 3mn
crw-rw-rw- 2 bin bin 205 0x0420c0 Mar 2 06:40 3mnb
crw-rw-rw- 2 bin bin 205 0x040000 Apr 8 2005 c4t0d0BEST
crw-rw-rw- 2 bin bin 205 0x040080 Apr 18 2003 c4t0d0BESTb
crw-rw-rw- 2 bin bin 205 0x040040 Apr 18 2003 c4t0d0BESTn
crw-rw-rw- 2 bin bin 205 0x0400c0 Mar 18 2005 c4t0d0BESTnb
crw-rw-rw- 2 bin bin 205 0x042000 May 1 2003 c4t2d0BEST
crw-rw-rw- 2 bin bin 205 0x042080 May 1 2003 c4t2d0BESTb
crw-rw-rw- 2 bin bin 205 0x042040 May 1 2003 c4t2d0BESTn
crw-rw-rw- 2 bin bin 205 0x0420c0 Mar 2 06:40 c4t2d0BESTnb
crw-rw-rw- 2 bin bin 205 0x050000 Apr 18 2003 c5t0d0BEST
crw-rw-rw- 2 bin bin 205 0x050080 Apr 18 2003 c5t0d0BESTb
crw-rw-rw- 2 bin bin 205 0x050040 Apr 18 2003 c5t0d0BESTn
crw-rw-rw- 2 bin bin 205 0x0500c0 Apr 18 2003 c5t0d0BESTnb
crw-rw-rw- 1 bin bin 205 0x050001 Apr 18 2003 c5t0d0DDS
crw-rw-rw- 1 bin bin 205 0x050081 Apr 18 2003 c5t0d0DDSb
crw-rw-rw- 1 bin bin 205 0x050041 Apr 18 2003 c5t0d0DDSn
crw-rw-rw- 1 bin bin 205 0x0500c1 Apr 18 2003 c5t0d0DDSnb
crw-rw-rw- 1 bin bin 205 0x050020 May 25 2004 c5t0d0s512BEST
crw-r--r-- 1 bin bin 205 0xfffffe Apr 18 2003 stape_config
[marvin]/dev/rmt:

And here is lssf * of /dev/rmt:

[marvin]/dev/rmt: /usr/sbin/lssf *
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t best density available at ad
dress 10/12/5.0.0 1m
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley best density available a
t address 10/12/5.0.0 1mb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t no rewind best density avail
able at address 10/12/5.0.0 1mn
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/12/5.0.0 1mnb
stape card instance 4 SCSI target 0 SCSI LUN 0 at&t best density available at ad
dress 10/8.0.0 2m
stape card instance 4 SCSI target 0 SCSI LUN 0 berkeley best density available a
t address 10/8.0.0 2mb
stape card instance 4 SCSI target 0 SCSI LUN 0 at&t no rewind best density avail
able at address 10/8.0.0 2mn
stape card instance 4 SCSI target 0 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/8.0.0 2mnb
stape card instance 4 SCSI target 2 SCSI LUN 0 at&t best density available at ad
dress 10/8.2.0 3m
stape card instance 4 SCSI target 2 SCSI LUN 0 berkeley best density available a
t address 10/8.2.0 3mb
stape card instance 4 SCSI target 2 SCSI LUN 0 at&t no rewind best density avail
able at address 10/8.2.0 3mn
stape card instance 4 SCSI target 2 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/8.2.0 3mnb
stape card instance 4 SCSI target 0 SCSI LUN 0 at&t best density available at ad
dress 10/8.0.0 c4t0d0BEST
stape card instance 4 SCSI target 0 SCSI LUN 0 berkeley best density available a
t address 10/8.0.0 c4t0d0BESTb
stape card instance 4 SCSI target 0 SCSI LUN 0 at&t no rewind best density avail
able at address 10/8.0.0 c4t0d0BESTn
stape card instance 4 SCSI target 0 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/8.0.0 c4t0d0BESTnb
stape card instance 4 SCSI target 2 SCSI LUN 0 at&t best density available at ad
dress 10/8.2.0 c4t2d0BEST
stape card instance 4 SCSI target 2 SCSI LUN 0 berkeley best density available a
t address 10/8.2.0 c4t2d0BESTb
stape card instance 4 SCSI target 2 SCSI LUN 0 at&t no rewind best density avail
able at address 10/8.2.0 c4t2d0BESTn
stape card instance 4 SCSI target 2 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/8.2.0 c4t2d0BESTnb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t best density available at ad
dress 10/12/5.0.0 c5t0d0BEST
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley best density available a
t address 10/12/5.0.0 c5t0d0BESTb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t no rewind best density avail
able at address 10/12/5.0.0 c5t0d0BESTn
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley no rewind best density a
vailable at address 10/12/5.0.0 c5t0d0BESTnb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t DDS1 DAT tape cartridge at a
ddress 10/12/5.0.0 c5t0d0DDS
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley DDS1 DAT tape cartridge
at address 10/12/5.0.0 c5t0d0DDSb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t no rewind DDS1 DAT tape cart
ridge at address 10/12/5.0.0 c5t0d0DDSn
stape card instance 5 SCSI target 0 SCSI LUN 0 berkeley no rewind DDS1 DAT tape
cartridge at address 10/12/5.0.0 c5t0d0DDSnb
stape card instance 5 SCSI target 0 SCSI LUN 0 at&t fixed_block_size 512 best de
nsity available at address 10/12/5.0.0 c5t0d0s512BEST
stape property table configuration device stape_config
[marvin]/dev/rmt:

Note that there is an entry which refers to a fixed_block_size (512 bytes) for a DDS3 drive.

This brings up an interesting aspect of HP-UX. In most flavor of UNIX the minor device number tells the system compression, density, rewind, etc. but in HP-UX there are not enough bits in the minor device number to describe all of these characteristics; instead, insf (install special file) creates an internal table and part of the minor number is the index into that table. This means, that identical device nodes (from the perspective of identical major/minor device number tuples) on different hosts could have completely different characteristics. For this reason, it is essential that insf beused to create tape device nodes rather than simply using mknod.

[Bill Hassell]

Yes, the lssf command does indeed say density but it is a leftover from the days of !/2" tapes. For modern tape drives, there is either BEST density or not, which just tells the driver to enable hardware compression on the tape drive.

Since AIX is often tied to mainframe data, it is understandable that fixed block sizes are part of the OS I/O for tapes. Without similar tools in HP-UX (and other Unices), the tool of choice is dd which can accept blocksize specifications. I wrote a script to create IBM standard labeled tapes with multiple files and translated to EBCDIC. It was significantly easier to do this in a shell script on the HP-UX side than to get the mainframe JCL jocks to figure out how to read a tar, cpio or even a simple cp on a tape.

[A. Clay Stephenson]

I can tell you this. Last year I was trying to read a DDS-2 tape from a PC running UnixWare on an HP-UX box. It was a cpio image that clearly stated it used 5k (cpio -B) that had been reblocked through dd to 100k blocks. I tried every combination imaginable and all I could read was a small portion of the tape. After getting on the SCO website I did find that they had fixed 512-byte blocking for DAT drive. I then created a 512-byte fixed block device node and then read in 100k input blocks and 5k output blocks and piped that to cpio -icB and it worked flawlessly. This both surprised me and delighted me because by that time I had had more than enough fun.

[Jim Sobiesczyk]

It sounds like you two are the Gurus on this subject...

Thanks for all the info.

[Jim Sobiesczyk]

Received my answere thru the final two respondents.