I have a SCSI DDS3 drive on which I use amanda on a 1.6.1/i386 system.

Everything works fine, except one odd case:

  1) amanda dumps overnight as usual (closes tape without rewinding)
  2) human hits eject button and puts in next tape

Then, amcheck, or amdump, whichever comes next, loses on trying to
open the tape:

Apr  4 10:00:00 foo /netbsd: st0(ahc0:0:3:0):  Check Condition on CDB: 0x00 00 00 00 00 00
Apr  4 10:00:00 foo /netbsd:     SENSE KEY:  Unit Attention
Apr  4 10:00:00 foo /netbsd:      ASC/ASCQ:  Not Ready To Ready Transition (Medium May Have Changed)
Apr  4 10:00:00 foo /netbsd: 

Future accesses are fine; only the first gets this.

I read some code (sys/dev/scsipi/st.c), and I'm guessing that the tape
is still 'mounted', and the error occurs because a program may have
expected to write after the backups.

If I do 'mt offline' and put in the new tape, then amcheck/amdump
works.  This closes the mount session.

This all seems a bit nonintuitive.  I don't see how someone typing 'mt
offline' is all that different from hitting the button, although the
former is aruguably under the control of the coordinated processes on
the computer that use a mount session.

I don't understand why MTREW does st_rewind instead of st_unmount.
Doing rewind explicitly on the non-rewinding device seems equivalent
to closing a regular device.

I probably should have amanda use the regular (rewinding) device
/dev/rst0, so the mount session ends on the last close.  (Amanda opens
the tape once for the whole run, not trusting that an OS will do the
whole mount session bit right.)

Any comments would be appreciated.