Partial success after rescanning the bus:
[ 504.487417] scsi 3:0:3:0: Sequential-Access HP Ultrium 4-SCSI W51D PQ: 0 ANSI: 5
[ 504.487443] scsi target3:0:3: Beginning Domain Validation
[ 504.494441] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494507] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494570] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494633] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494696] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494758] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494822] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494885] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.494948] scsi 3:0:3:0: mptspi: ioc1: IDP:ON
[ 504.500745] scsi target3:0:3: Domain Validation skipping write tests
[ 504.500750] scsi target3:0:3: Ending Domain Validation
[ 504.500821] scsi target3:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU RTI PCOMP (6.25 ns, offset 64)
[ 504.502881] scsi 3:0:3:0: alua: supports implicit TPGS
[ 504.504309] scsi 3:0:3:0: alua: port group 00 rel port ffffffff
[ 504.504964] scsi 3:0:3:0: alua: port group 00 state A preferred supports tolusnA
[ 504.504969] scsi 3:0:3:0: alua: Attached
[ 504.506534] scsi 3:0:3:0: Attached scsi generic sg1 type 1
[ 504.534442] st: Version 20101219, fixed bufsize 32768, s/g segs 256
[ 504.535363] st 3:0:3:0: Attached scsi tape st0
[ 504.535370] st 3:0:3:0: st0: try direct i/o: yes (alignment 512 B)
[ 504.548919] osst :I: Tape driver with OnStream support version 0.99.4
The drive was detected correctly. And I believe the second 3 is the SCSI bus id, which was set to 3.
Also getting the status:
# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Beginning of Tape, Online and:
GMT_IM_REP_EN(x): Immediate report mode. This bit is set if there are no guarantees that the data has been physically written to the tape when the write call returns.
It is set zero only when the driver does not buffer data and the drive is set not to buffer data.
Which I suppose isn’t a problem.
But hardware encryption does not seem to work:
# ../../../bin/stenc -f /dev/st0 -e on
Enter key in hex format:
Re-enter key in hex format:
Provided key length is 128 bits.
Key checksum is 550.
Set encryption using this key? [y/n]: y
Turning on encryption on device '/dev/nst0'...
Sense Code: Illegal Request (0x05)
Additional data: 0x00000000000000000000000000000000
Error: Turning encryption on for '/dev/nst0' failed!
Which I sort of expected as the drive doesn’t have the Encryption LED on front panel. But I can do software encryption.
The drive is making winding type of noises so we will see what will come out.
tar -cvf - /directory | pbzip2 -9 | aespipe -e AES256 -P keys.txt | dd of=/dev/st0
AES256 encrypted bzip2 compressed tar archive.
Not getting I/O errors or anything, so I suppose the data must be going somewhere.
It definitely works. Wrote two separate tar archives on a tape so I am practically ready to do some serious backing up. But I am not quite comfortable doing multi-tape backups.
# sg_logs /dev/nst0 -p 12
HP Ultrium 4-SCSI W51D
Sequential access device page (ssc-3)
Data bytes received with WRITE commands: 2 GB
Data bytes written to media by WRITE commands: 2 GB
Data bytes read from media by READ commands: 2 GB
Data bytes transferred by READ commands: 2 GB
Cleaning action not required (or completed)
Very old tape drive apparently:
# sg_logs /dev/nst0 -p 20
HP Ultrium 4-SCSI W51D
Device statistics page (ssc-3 and adc)
Lifetime media loads: 1214
Lifetime cleaning operations: 1
Lifetime power on hours: 49012
Lifetime media motion (head) hours: 7370
Lifetime metres of tape processed: 50738775
I don’t even understand how 50 000 km of tape is even possible. But if that is even half true, then that says something about the validity of tape as a backup solution.
Not sure why I was getting extremely poor performance, but either changing from aespipe to openssl, or from 256k block size to 1,616,940 byte block size made a huge difference, and now this is what I am getting for writing and reading:
1913264976 bytes (1.9 GB) copied, 47.6988 s, 40.1 MB/s
1913264976 bytes (1.9 GB) copied, 41.9134 s, 45.6 MB/s
Which are pretty damn good speeds and will let me backup 800GB in 6 hours.
And this seems so good that during weekend I will probably try to see what I need to backup. I still don’t know how I should handle the 800GB per tape limit, because I do not want to have backups span multiple tapes. Unless they are actually easy to do and reliable.
Speed with large files seems to be closer to 100MB/s than the 45MB/s reported above.
But one problem is verification, and how to do it. Not absolutely necessary but better than blindly trusting the tape or the drive.