On Thu, Jul 2, 2026 at 1:33 AM Christian Corti via cctalk <
cctalk(a)classiccmp.org> wrote:
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.
I tried per your suggestion
dd if=/dev/nst0 bs=32768 count=1 (to read one single block)
I got the same results as before, the tape is attempted, not advanced. 0
bytes in/out, 0 bytes copied.
Thank you for your suggestion. I can repeat this test with all 4 tapes I
have on hand, they all have identical results. I have no issue reading
1600 pe tapes on this M4 tape unit. With 800 bpi tapes, regardless of the
bs values and other tricks, I would think I would read something before it
bombs.
Is there a way to force the tape to advance and try after a certain
distance of tape? Maybe the beginning of the tape is bad but I can recover
data from the inner parts?
I am open to suggestions, but I am wondering if there is a drive issue.
Alignment, etc.
Best
Bill