Re: st.c update has broken dump multi-tape support

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

Hi Brett !

A quick analysis leaves me to believe that the culprit is in this commit:

   revision 1.234
   date: 2018-03-24 09:08:19 +0100;  author: mlelstv;  state: Exp;
   lines: +176 -134;  commitid: xU4Kh6YFLfDywGvA;
   branches:  1.234.2;
   Use separate lock to protect internal state and release locks when
   calling biodone.

Here the logic for ST_EARLY_WARN got lost. So the EOM always delivers 
EIO instead

of a 0 write count when EOM is reported by the drive and early warning 
is enabled.

The early warning logic is described in st.4 as

EOM HANDLING
     Attempts to write past EOM and how EOM is reported are handled 
slightly
     differently based upon whether EARLY WARNING recognition is enabled in
     the driver.

     If EARLY WARNING recognitions is not enabled, then detection of 
EOM (as
     reported in SCSI Sense Data with an EOM indicator) causes the write
     operation to be flagged with I/O error (EIO).  This has the effect for
     the user application of not knowing actually how many bytes were read
     (since the return of the read(2) system call is set to −1).

     If EARLY WARNING recognition is enabled, then detection of EOM (as
     reported in SCSI Sense Data with an EOM indicator) has no immediate
     effect except that the driver notes that EOM has been detected. If the
     write completing didn't transfer all data that was requested, then the
     residual count (counting bytes not written) is returned to the user
     application. In any event, the next attempt to write (if that is 
the next
     action the user application takes) is immediately completed with 
no data
     transferred, and a residual returned to the user application 
indicating
     that no data was transferred.  This is the traditional UNIX EOF
     indication. The state that EOM had been seen is then cleared.

     In either mode of operation, the driver does not prohibit the user
     application from writing more data, if it chooses to do so. This will
     continue up until the physical end of media, which is usually 
signalled
     internally to the driver as a CHECK CONDITION with the Sense Key 
set to
     VOLUME OVERFLOW. When this or any otherwise unhandled error occurs, an
     error return of EIO will be transmitted to the user application.  This
     does indeed mean that if EARLY WARNING is enables and the device
     continues to set EOM indicators prior to hitting physical end of 
media,
     that an indeterminate number of 'short write returns' as described 
in the
     previous paragraph will occur. However, the expected user application
     behaviour (in common with other systems) is to close the tape and 
rewind
     and request another tape upon the receipt of the first EOM indicator,
     possibly after writing one trailer record.

dump abort on EIO. dump will switch tapes if it gets a zero write count.

Thus the 1.234 commit should be fixed with respect to EOM signalling.

Frank


On 06/09/21 02:47, Brett Lymn wrote:
> Folks,
>
> I don't perform a tape backup nor update this machine very often so it
> has taken a while for me to spot this.
>
> I backup to tape which takes a few tapes to complete, in the past this
> has worked fine, when one tape is full dump recognises this and prompts
> for a new tape.
>
> I attempted a backup a couple of days ago and now dump says "write
> error" and then asks if it should restart the dump, answering yes does
> restart the dump from the beginning, answering no causes dump to exit.
>
> As I said, this machine does not get updated often so I suspect this
> problem has been there for a while.  The kernel was built with v1.240 of
> st.c, this version causes dump to misbehave.  I reverted st.c back to
> v1.231 (this was the version of st.c that was used in the kernel that
> made the last successful backup).  After adding a couple of FALLTHROUGH
> comments to get v1.231 to compile I booted to this kernel and found that
> dump behaved correctly again.
>
> Given the above it looks like a change to st.c between v1.231 and v1.240
> has broken multi-tape dumps.  Fortunately most of the commits in that
> bracket are cosmetic, one that does stand out is v1.238 which does
> modify the tape position handling.  I will try a kernel that
> incorporates v1.237 of st.c and see what happens.  Unfortunately,
> testing is a very slow process as it takes about 3 hours to fill a tape
> though I may be able to reduce that by using a lto-1 tape instead which
> should halve the time taken to fill a tape.