Unlike some DAT drives, Quantum's DLT tape drives don't automatically eject
the cartridge after the "offline" operation completes. The cartridge stays
in the drive in an unloaded condition. Cartridge ejection and removal either
requires a manual operation (for stand-alone drives) or can be done via
robotics (for multi-drive units such as tape libraries).

For this reason, DLT drives also support a SCSI "LOAD" command. When there
is an unloaded cartridge in the drive, issuing a SCSI LOAD would cause the
cartridge to become available, with the head positioned at the beginning of
the tape. This operation also uses SCSI opcode 0x1B. There's a bit in the
command descriptor block that determines whether the operation requested is
"load" or "unload" (it's bit 0 of byte 4 in the six-byte SCSI command).

Providing support for "mt -f /dev/st0 load" would probably benefit people
using DLT drives. For reference, the "mt" implementation in the "mt-st"
package currently provides this feature.

- Ganesh.

I understand this problem and I'm aware that this functionality has been
hacked into mt-st.  Unfortunately, the guy who added the SCSI support
to mt used the BSD based mt source for his code base which is inferior
(doesn't provide as many useful features) to GNU mt, included with cpio.
This is a shame, because it creates a situation of conflicting versions
of mt.

Realizing this problem back in 1996, I hacked the SCSI support provided
by mt-st at the time into Debian's version of GNU mt.  Since then,
however, the mt-st author has added new features and Debian's mt has
fallen behind.  A couple of months ago, I posted a message to the Debian
mailing lists explaining this problem and asking for advice.  I wanted
opinions on whether it would be useful to continue to port all of the
new changes from mt-st to GNU mt or whether it would be better to
provide an mt-st package.  I received NO response, which implies that
the greater Debian developer community doesn't care.

This situation is further complicated by the troubling fact that the
GNU cpio package is no longer being developed upstream.  Instead, it
and tar are being merged into a new set of software called paxutils,
which will provide the combined functionality of both.  I assume that mt
will follow cpio, and once paxutils is officially released as a stable
version, I will no longer maintain mt.

Thus, I have received no help, and I now do not have the time required
for the extensive work required to fold the mt-st features into GNU mt.
(I've done this sort of thing once, and I know that there is quite a bit
of work required to do this.)  Therefore, I am sorry, but if it is left
to my efforts alone to implement this feature into mt, then it will not
be done anytime soon.

Brian