st.c update has broken dump multi-tape support

[Brett Lymn <blymn%internode.on.net@localhost>]

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.

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"