1

I'm dealing with a couple of DDS-2 tapes, the owner of which says they were written long ago on a Solaris workstation, but I'm trying to read them in a Linux environment, since with other tapes I've never had problems using dd to dump the entire contents (e.g. tapes written using DOS, Windows NT, Linux tar, etc).

But with these tapes, something weird happens: I'm able to get the first 32KB from the tape, which is the first "file" that seems to contain the volume header, but can't read any data after that, as if mt believes it has reached end-of-tape.

The volume header suggests that there's definitely plenty of data that is supposed to follow, but the tape driver believes that the tape ends there. What could be going on? Did Solaris write these tapes in some sort of nonstandard way? Is there a way to make dd read the tape at an even "lower level", ignoring end-of-file markers?

Improve this question
6
  • What block size ("bs" argument) you used when "dd" command? As you might know, the actual value of bs depends on the software that was used to write the tape. Commented Apr 10, 2021 at 7:53
  • I wasn't specifying a block size, but even if I try various different block sizes the result is the same. If it was an issue of block sizes, wouldn't I be getting different types of errors than an end-of-tape condition? Commented Apr 10, 2021 at 12:24
  • Does mt -f /dev/nrst0 eod; mt -f /dev/nrst0 status show you're at file 1 or something else? Commented Apr 11, 2021 at 19:07
  • @MarkPlotnick Yep, the status at file 1 is EOD, which I suppose means that the drive believes that the data ends there. But this is very strange because there are four tapes that have the same behavior. I'm starting to suspect that the backup software that wrote these tapes somehow corrupted them (e.g. reinitialized the tape, causing the EOD marker to be written at the beginning)? I don't suppose there are ways to make the drive read past EOD? Commented Apr 11, 2021 at 20:40
  • I don't know how to read past EOD. Are there any error messages in the system logs? Might try mt -f /dev/rst0 setblk 0 to ensure the drive is in variable block size mode, and try to read the tape again. Commented Apr 11, 2021 at 22:25

1 Answer 1

Reset to default
1

So, this is a bit weird, but it turned out to be a problem with the tape drive that I was using. I had a Seagate STD2401 drive, which is DDS-4, and is supposed to be read-only compatible with DDS-2 tapes. And indeed I've used it to read multiple DDS-2 tapes in the past.

However, I just obtained an IBM 19P0802 drive (also DDS-4), and it reads the same tapes without any issues whatsoever! (i.e. the places where the Seagate drive thought there was an EOD marker, the IBM drive interprets correctly as data. Who would have thought.)

Improve this answer
2
  • 1
    This answer made me read the German Wikipedia article about DDS tapes. It includes anecdotal information about the down-sides of helical scan method: Due to slight differences in the recording angle, it is quite possible that reading a tape does not just require the same brand and model of drive, but actually the very same drive the tape has been written to with. Scary! Commented Apr 14, 2021 at 0:20
  • @Hermann Aha, very interesting! It's a shame that the German article doesn't provide a citation for that statement, otherwise I would add that info to the English wiki article, too. Commented Apr 14, 2021 at 18:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.