On Thu, Jul 2, 2026 at 1:33 AM Christian Corti via cctalk < [email protected]> 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
