vtltape oddity with rewoff when tape is not already rewound (at BOT/BOP)

[Tim Jones]

Hi Mark,

I've just discovered that if I have a written tape positioned at EOD, issuing a rewoff from mt-st does not rewind the tape, but does mark the tape as unloaded (DR_OPEN):

root@linux64:~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x58 (LTO-5).
Soft error count since last status=0
General status bits on (9010000):
 EOD ONLINE IM_REP_EN
root@linux64:~# mt -f /dev/nst0 rewoff
root@linux64:~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (8050000):
 EOD DR_OPEN IM_REP_EN

Also, issuing a LOAD command does not load the tape, leaving things in that state:

root@linux64:~# mt -f /dev/nst0 load
root@linux64:~# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (8050000):
 EOD DR_OPEN IM_REP_EN

[Mark Harvey]

Many thanks for the bug report.

'vtltape' is not keeping enough persistent data between unload -> load to be able to recover from this sequence.

If the robot is involved, the 'barcode' is passed to the drive via the message queue. Performing a 'mt -f xxx offline / load' directly  means the 'barcode' is not being passed to the load.

Fixing this shortly.

Cheers

[Tim Jones]

Obviously, you've clobbered it.  And, it's sorted for the 5.0 kernel (Fedora 30).  

I pulled the current source (as of 5/2 at 08:30 PDT) and it built on Fedora 30 with no warnings and everything just worked out of the gate.

I'll be attacking a few 4.x systems later today.

Thanks for attacking this.

Tim