Re: st(4) and mt eom

[Frank Kardel <kardel%netbsd.org@localhost>]

Hi John !

This seems to be a long standing deficiency of the driver. Looking at 
the SCSI spec it is recommended to issue a READ POSITION command

get the current position. Looking at the spec and code it should be 
possible to handle the SP_EOM case better with respect to the position 
information

by issuing READ POSITION (service action code 6 = LONG FORM) at that 
point to set the correct position.

I also ran bacula (now I run freshly ported bareos 18.2.5 for HW 
encryption, tapealert) with HW EOM set to false. btape test made those 
recommendation a long time ago.

Time permitting I try to update the driver this week, would you be 
willing to test?

Frank



On 03/20/19 19:02, John Nemeth wrote:
>       If you issue an "mt eom" (forward to end of media), the driver
> loses track of the tape position.  This seriously messes with
> Bacula's tape handling.  Since Bacula expects the driver not to
> lose the tape position I get the feeling there are other operating
> systems that don't.  I found this code in st.c:st_space():
>
>          error = scsipi_command(st->sc_periph, (void *)&cmd, sizeof(cmd), 0, 0,
>              0, ST_SPC_TIME, NULL, flags);
>
>          if (error == 0 && (st->flags & ST_POSUPDATED) == 0) {
>                  number = number - st->last_ctl_resid;
>                  if (what == SP_BLKS) {
>                          if (st->blkno != -1)
>                                  st->blkno += number;
>                  } else if (what == SP_FILEMARKS) {
>                          if (st->fileno != -1) {
>                                  st->fileno += number;
>                                  if (number > 0)
>                                          st->blkno = 0;
>                                  else if (number < 0)
>                                          st->blkno = -1;
>                          }
>                  } else if (what == SP_EOM) {
>                          /* This loses us relative position. */
>                          st->fileno = st->blkno = -1;
>                  }
>          }
>          return error;
> }
>
> Notice the SP_EOM case.  Can any SCSI experts, in particular SCSI
> tape experts, shed some light on this and what can be done about
> it?
>
>       I have found a workaround for Bacula which is to tell it about
> this problem.  If you do that, Bacula will do "mt fsf 65535" (and
> pray that there aren't more files then that on the tape).  The tape
> I have with the largest number of files is at 1186, so this will
> do for now.  Still, it would be nice to fix the underlying problem.
>
>       For those wondering, my bacula-sd.conf contains:
>
> Device {
>    Name = LTO-4a
>    Archive Device = /dev/nrst0
>    Device Type = Tape
>    Media Type = LTO-4
>    AutoChanger = yes
>    LabelMedia = no
>    Drive Index = 0
>    AlwaysOpen = yes;
>    Removable Media = yes;
>    Random Access = no;
>    Maximum File Size = 2GB
>    Automatic Mount = yes;               # when device opened, read it
>    Spool Directory = /bacula/spool-sd
>    Hardware End of Medium = No
>    #Fast Forward Space File = No
>    BSF at EOM = yes
>    #
>    # New alert command in Bacula 9.0.0
>    #  Note: you must have the sg3_utils (rpms) or the
>    #        sg3-utils (deb) installed on your system.
>    #        and you must set the correct control device that
>    #        corresponds to the Archive Device
> #  Control Device = /dev/sg??  # must be SCSI ctl for /dev/nrst0
> #  Alert Command = "/usr/pkg/libexec/bacula/tapealert %l"
>
>    # Enable the Alert command only if you have the mtx package loaded
> # Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
> # If you have smartctl, enable this, it has more info than tapeinfo
> # Alert Command = "sh -c 'smartctl -H -l error %c'"
> }