A perl script for storing multiple dumps on a single tape was ported from a
DEC/OSF1 Alpha to my Linux computer. On the Red Hat machine, I found that
unexpected tape drive rewinds were occurring. (The tape drive is
a Sony SDT10000 DDS-4 tape drive.) The perl script issues
several "mt" commands and I found that each "mt" command causes the tape
drive to rewind. (The commands are "mt status" and "mt fsf 1")
I altered the script so that the commands are now "mt -f /dev/nst0
status" and "mt -f /dev/nst0 fsf 1" and the unexpected rewinding stopped.
So I have a workaround, but I still believe the driver is misbehaving.
This doesn't seem exactly the same as the bugs reported previously.
The pernicious part of this is that it's possible to think you've succeeded
in several backups, but the dump is simple writing a file, rewinding,
then writing another. Using restore (with the problematic "fsf 1"
command) causes a listing, a rewind, another listing, etc. So on the
surface, all appears to work.
This is what happens when moving between operating systems. It never
occurred to me that /dev/tape needs to be a link to /dev/nst0 rather
that /dev/st0. After making that change, the "mt" commands now appear to work
normally. However should an "mt status" command really rewind the tape
even if the tape device is /dev/st0?