On Wed, 1 Jul 2026, Bill Degnan wrote:
But when I try to actually read a tape I get errors
Here are examples of the tape read commands, there are many variations one
can try:
dd if=/dev/nst0 of=block1.bin
dd if=dev/nst0 of /dev/null bs=1024
etc
I would open a 2nd window and run the following command to view the system
messages while the dd program is running
dmesg | tail -50
result example:
[ 1802.404408] st0: Failed to read 1326 byte block with 1024 byte transfer.
[ 1813.881884] st0: Failed to read 3846 byte block with 1024 byte transfer
The conclusion is very simple: you cannot use dd for tapes with variable
block sizes! You must issue individual read calls and parse the result
length for each tape block.
I don't think setblk 0 is being implemented (use variable block size), but I
don't think this is a fixed-block vs variable block issue. I think that
Yes, it is. dd can only handle fixed block length. You may try dd with
'dd if=/dev/nst0 bs=32768 count=1' to read one single block.
Linux' st driver is issuing fixed-size read internally and failing when the
drive returns a different record size than expected. There is no
No. The read system call returns the actual size. You issue a read(fd,
buffer, MAX_BLOCK_LENGTH) and look at the return value that tells you the
length of the actual block.
Result - The fsf command runs and rolls the entire tape, never finds a file
marker to indicate beginning of file. This indicates variable-block,
filemark-less (or nonstandard filemark) 9-track dump tapes, like you find
in IBM systems.
Ehm, and you're sure that there is a second file on the tape? May it be a
backup with one single file that fills the entire tape?
Christian
