Re: st.c update has broken dump multi-tape support
On Fri, Jun 11, 2021 at 10:55:29PM -, Michael van Elst wrote: > mlel...@serpens.de (Michael van Elst) writes: > > >I'm currently testing > >http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff > > Works for me: > works for me too, thanks. -- 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"
Re: st.c update has broken dump multi-tape support
On Sat, Jun 12, 2021 at 11:17:14AM +0200, Frank Kardel wrote: > Hi ! > > Look pretty good so far, ... can we remove following marked lines which are > already > taken care of in ststart1 complete case? I guess so. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
Hi !
Look pretty good so far, ... can we remove following marked lines which
are already
taken care of in ststart1 complete case?
/*
* only FIXEDBLOCK devices have pending I/O or space operations.
*/
if (st->flags & ST_FIXEDBLOCKS) {
/*
* If we are at a filemark but have not reported it yet
* then we should report it now
*/
if (st->flags & ST_AT_FILEMARK) {
if ((bp->b_flags & B_READ) == B_WRITE) {
/*
* Handling of ST_AT_FILEMARK in
* st_space will fill in the right file
* mark count.
* Back up over filemark
*/
if (st_space(st, 0, SP_FILEMARKS, 0)) {
error = EIO;
goto out;
}
} else {
>>> bp->b_resid = bp->b_bcount;
error = 0;
st->flags &= ~ST_AT_FILEMARK;
goto out;
}
}
}
/*
* If we are at EOM but have not reported it
* yet then we should report it now.
*/
if (st->flags & (ST_EOM_PENDING|ST_EIO_PENDING)) {
>> bp->b_resid = bp->b_bcount;
error = 0;
if (st->flags & ST_EIO_PENDING)
error = EIO;
st->flags &= ~(ST_EOM_PENDING|ST_EIO_PENDING);
goto out;
}
Frank
On 06/11/21 21:10, Michael van Elst wrote:
bl...@internode.on.net (Brett Lymn) writes:
Here is the patch that makes multi-tape dumps work for me:
I'm currently testing
http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff
It's a bit cumbersome to do multi-tape dumps if your disk has 11GB
data and the tape fits 40GB uncompressed.
Re: st.c update has broken dump multi-tape support
On Fri, Jun 11, 2021 at 07:10:16PM -, Michael van Elst wrote: > bl...@internode.on.net (Brett Lymn) writes: > > >Here is the patch that makes multi-tape dumps work for me: > > I'm currently testing > > http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff > That looks good to me. > It's a bit cumbersome to do multi-tape dumps if your disk has 11GB > data and the tape fits 40GB uncompressed. > Yes, that would be tedious. Perhaps you could create a test tape with a few backups on it and use mt to position to the end of them and dump to /dev/nrst? I will give the patch a go on my system, my data hoard at the moment spans 3 lto2 tapes. -- 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"
Re: st.c update has broken dump multi-tape support
mlel...@serpens.de (Michael van Elst) writes:
>I'm currently testing
>http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff
Works for me:
DUMP: Found /dev/rdk0 on / in /etc/fstab
DUMP: Date of this level 0 dump: Sat Jun 12 00:24:45 2021
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdk0 (/) to /dev/nrst0
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 11948298 tape blocks.
DUMP: Volume 1 started at: Sat Jun 12 00:24:54 2021
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 18.18% done, finished in 0:22
DUMP: 39.37% done, finished in 0:15
DUMP: 56.67% done, finished in 0:11
DUMP: End of tape detected
DUMP: Closing /dev/nrst0
DUMP: Volume 1 completed at: Sat Jun 12 00:44:21 2021
DUMP: Volume 1 took 0:19:27
DUMP: Volume 1 transfer rate: 7380 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
DUMP: Volume 2 started at: Sat Jun 12 00:45:06 2021
DUMP: Volume 2 begins with blocks from inode 1448282
DUMP: 72.08% done, finished in 0:07
DUMP: 87.50% done, finished in 0:03
DUMP: 11948472 tape blocks on 2 volumes
DUMP: Volume 2 completed at: Sat Jun 12 00:54:40 2021
DUMP: Volume 2 took 0:09:34
DUMP: Volume 2 transfer rate: 5812 KB/s
DUMP: Date of this level 0 dump: Sat Jun 12 00:24:45 2021
DUMP: Date this dump completed: Sat Jun 12 00:54:40 2021
DUMP: Average transfer rate: 6596 KB/s
DUMP: level 0 dump on Sat Jun 12 00:24:45 2021
DUMP: Closing /dev/nrst0
DUMP: DUMP IS DONE
Can you please verify?
Re: st.c update has broken dump multi-tape support
bl...@internode.on.net (Brett Lymn) writes: >Here is the patch that makes multi-tape dumps work for me: I'm currently testing http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/st.diff It's a bit cumbersome to do multi-tape dumps if your disk has 11GB data and the tape fits 40GB uncompressed.
Re: st.c update has broken dump multi-tape support
On Fri, Jun 11, 2021 at 09:00:50AM +0200, Frank Kardel wrote:
> Hi !
>
> ST_EOM_PENDING is set in st_interpret_sense()
>
> - always for fixed block mode on EOM condition
>
> - if EWARN enabled and EOM condition for variable block size
>
yes indeed.
Here is the patch that makes multi-tape dumps work for me:
Index: st.c
===
RCS file: /cvsroot/src/sys/dev/scsipi/st.c,v
retrieving revision 1.240
diff -u -r1.240 st.c
--- st.c27 Dec 2019 09:41:51 - 1.240
+++ st.c11 Jun 2021 11:23:10 -
@@ -1338,7 +1338,12 @@
mutex_exit(>sc_iolock);
if (error != 0) {
- bp->b_error = error;
+ /* if ststart1 returns EIO, don't return that if
+* an EOM is pending otherwise multi-tape dumps
+* will error instead of triggering a tape change.
+*/
+ if (!((error == EIO) && (st->flags & ST_EOM_PENDING)))
+ bp->b_error = error;
bp->b_resid = bp->b_bcount;
biodone(bp);
}
--
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"
Re: st.c update has broken dump multi-tape support
Hi ! ST_EOM_PENDING is set in st_interpret_sense() - always for fixed block mode on EOM condition - if EWARN enabled and EOM condition for variable block size Frank. On 06/10/21 23:59, Brett Lymn wrote: On Thu, Jun 10, 2021 at 05:38:34PM +0200, Michael van Elst wrote: Sorry, it doesn't fix the EOM handling, just the biodone. mea culpa... I should take more time before replying... I still have to understand the EOM logic :) I will post up a diff later that appears to work for me. From what the code used to do and the description Frank posted EOM is indicated by a 0 length write with no error iff the early warning flag is set. I haven't checked but I ASSuME that ST_EOM_PENDING will only be set if the early warning flag is on.
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 11:10:23AM +0200, Frank Kardel wrote: > > I meant the section in ststart1 where error is set to zero followed by goto > out inf the fixed blocksize part. > Sorry, yes you are correct. I ignored that because I am using variable blocks...oops. -- 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"
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 05:38:34PM +0200, Michael van Elst wrote: > > Sorry, it doesn't fix the EOM handling, just the biodone. > mea culpa... I should take more time before replying... > I still have to understand the EOM logic :) > I will post up a diff later that appears to work for me. From what the code used to do and the description Frank posted EOM is indicated by a 0 length write with no error iff the early warning flag is set. I haven't checked but I ASSuME that ST_EOM_PENDING will only be set if the early warning flag is on. -- 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"
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 04:57:21PM +0200, Frank Kardel wrote: > Hi ! > > I assumed Michael was proposing a solution for the missing biodone() in the > fixed block path (though that part was missing in the patch). Yes, biodone needs to be called without the lock being held, so not in ststart1(). Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
Hi !
I assumed Michael was proposing a solution for the missing biodone() in
the fixed block path (though that part was missing in the patch).
We should try to fix both issues (write return code and missing biodone)
with hopefully minimal changes without sacrificing clarity and abstraction.
IMHO ststart() should manage the interface to ststart1() but not look
into specific bits (ST_EOM_PENDING) and ststart1() should signal
ststart() errno and biodone(). Thus I did see
merit in Michael's proposal. This is a style discussion, however.
On a more important note: Looking into the code again we also seem to
miss clearing ST_{EOM,EIO}_PENDING that is something that was present in
1.231. Clearing that would get st.c
in-line again with st(4).
Frank
On 06/10/21 15:52, Brett Lymn wrote:
On Thu, Jun 10, 2021 at 12:13:22PM +0200, Michael van Elst wrote:
On Thu, Jun 10, 2021 at 12:02:19PM +0200, Michael van Elst wrote:
If you don't like the fake errno, the function needs to return
two values, the error value and a boolean to finish the
unqueued request. Cleaner, but more changes.
E.g. (not even compile-tested):
I don't think that is quite right. At line 1204 error is set to EIO, even with
your changes
b_error will still get set to EIO when EOM_PENDING is true. Previously b_error
was only set
b_error would be set to EIO in previous versions this would only happen if
there was no
ST_EOM_PENDING flag set. I did a much smaller change in ststart inside
the if at line 1290 I added a check to only set b_error to the value of error
unless error
==EIO and st->flags contains ST_EOM_PENDING. This change made dump perform as
expected and
prompt for a new tape.
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 12:13:22PM +0200, Michael van Elst wrote: > On Thu, Jun 10, 2021 at 12:02:19PM +0200, Michael van Elst wrote: > > > If you don't like the fake errno, the function needs to return > > two values, the error value and a boolean to finish the > > unqueued request. Cleaner, but more changes. > > E.g. (not even compile-tested): > I don't think that is quite right. At line 1204 error is set to EIO, even with your changes b_error will still get set to EIO when EOM_PENDING is true. Previously b_error was only set b_error would be set to EIO in previous versions this would only happen if there was no ST_EOM_PENDING flag set. I did a much smaller change in ststart inside the if at line 1290 I added a check to only set b_error to the value of error unless error ==EIO and st->flags contains ST_EOM_PENDING. This change made dump perform as expected and prompt for a new 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"
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 12:02:19PM +0200, Michael van Elst wrote:
> If you don't like the fake errno, the function needs to return
> two values, the error value and a boolean to finish the
> unqueued request. Cleaner, but more changes.
E.g. (not even compile-tested):
Index: st.c
===
RCS file: /cvsroot/src/sys/dev/scsipi/st.c,v
retrieving revision 1.240
diff -p -u -r1.240 st.c
--- st.c27 Dec 2019 09:41:51 - 1.240
+++ st.c10 Jun 2021 10:11:47 -
@@ -343,7 +343,7 @@ static int st_mount_tape(dev_t, int);
static voidst_unmount(struct st_softc *, boolean);
static int st_decide_mode(struct st_softc *, boolean);
static voidststart(struct scsipi_periph *);
-static int ststart1(struct scsipi_periph *, struct buf *);
+static int ststart1(struct scsipi_periph *, struct buf *, int *);
static voidstrestart(void *);
static voidstdone(struct scsipi_xfer *, int);
static int st_read(struct st_softc *, char *, int, int);
@@ -1183,13 +1183,13 @@ abort:
* ststart() is called with channel lock held
*/
static int
-ststart1(struct scsipi_periph *periph, struct buf *bp)
+ststart1(struct scsipi_periph *periph, struct buf *bp, int *errnop)
{
struct st_softc *st = device_private(periph->periph_dev);
struct scsipi_channel *chan = periph->periph_channel;
struct scsi_rw_tape cmd;
struct scsipi_xfer *xs;
- int flags, error;
+ int flags, error, complete = 1;
SC_DEBUG(periph, SCSIPI_DB2, ("ststart1 "));
@@ -1299,11 +1299,14 @@ ststart1(struct scsipi_periph *periph, s
error = scsipi_execute_xs(xs);
/* with a scsipi_xfer preallocated, scsipi_command can't fail */
KASSERT(error == 0);
+ if (error == 0)
+ complete = 0;
out:
mutex_exit(chan_mtx(chan));
- return error;
+ *errnop = error;
+ return complete;
}
static void
@@ -1312,7 +1315,7 @@ ststart(struct scsipi_periph *periph)
struct st_softc *st = device_private(periph->periph_dev);
struct scsipi_channel *chan = periph->periph_channel;
struct buf *bp;
- int error;
+ int error, complete;
SC_DEBUG(periph, SCSIPI_DB2, ("ststart "));
@@ -1325,19 +1328,20 @@ ststart(struct scsipi_periph *periph)
iostat_busy(st->stats);
mutex_exit(>sc_iolock);
- error = ststart1(periph, bp);
+ complete = ststart1(periph, bp, );
mutex_enter(>sc_iolock);
- if (error != 0)
+ if (complete) {
iostat_unbusy(st->stats, 0,
((bp->b_flags & B_READ) == B_READ));
- if (error == EAGAIN) {
- bufq_put(st->buf_defer, bp);
- break;
+ if (error == EAGAIN) {
+ bufq_put(st->buf_defer, bp);
+ break;
+ }
}
mutex_exit(>sc_iolock);
- if (error != 0) {
+ if (complete) {
bp->b_error = error;
bp->b_resid = bp->b_bcount;
biodone(bp);
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
On Thu, Jun 10, 2021 at 11:10:23AM +0200, Frank Kardel wrote: > Hi Brett, > > I meant the section in ststart1 where error is set to zero followed by goto > out inf the fixed blocksize part. The biodone is missing, but also other parts. We have 5 cases. - I/O request is queued, error == 0. -> will be finished in callback. - I/O request is queued, error != 0. -> ststart calls biodone. - I/O request is not queued, error == EAGAIN -> ststart requeues request - I/O request is not queued, error != 0 -> ststart calls biodone. and - I/O request is not queued, error == 0 -> this is broken. I would make the last case return error == -1 instead (!= any possible errno value). In ststart errno is checked != 0, so it will - finish the I/O request for iostat. - call biodone The latter needs an adjustment like: bp->b_error = error < 0 ? 0 : error; so that the fake errno is replaced with end-of-file. If you don't like the fake errno, the function needs to return two values, the error value and a boolean to finish the unqueued request. Cleaner, but more changes. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: st.c update has broken dump multi-tape support
Hi Brett,
I meant the section in ststart1 where error is set to zero followed by
goto out inf the fixed blocksize part.
on that path the biodone() would be missing - just something I noticed
when looking at the code.
/*
* only FIXEDBLOCK devices have pending I/O or space operations.
*/
if (st->flags & ST_FIXEDBLOCKS) {
/*
* If we are at a filemark but have not reported it yet
* then we should report it now
*/
if (st->flags & ST_AT_FILEMARK) {
if ((bp->b_flags & B_READ) == B_WRITE) {
/*
* Handling of ST_AT_FILEMARK in
* st_space will fill in the right file
* mark count.
* Back up over filemark
*/
if (st_space(st, 0, SP_FILEMARKS, 0)) {
error = EIO;
goto out;
}
} else {
bp->b_resid = bp->b_bcount;
error = 0;
st->flags &= ~ST_AT_FILEMARK;
>>/* XXX missing a biodone() here? */
goto out;
}
}
}
Frank
On 06/10/21 08:42, Brett Lymn wrote:
Hi Frank,
On Thu, Jun 10, 2021 at 07:45:25AM +0200, Frank Kardel wrote:
Could you check whether my suspicion that biodone() may be missing the
ststart1 function in the
It is missing there but is called in ststart if the error is != 0 after
the ststart1 call. I was going to update the ststart function to do
something very close to what you have done.
I have not tested the patch as my machine with the tapes is remote and has
no remote console
and I don't want to brick that while being off-site.
That's ok - I can test here without harming anything, the machine the
tape drive is attached to has to be booted to windows for $WORK during
the day so my testing window is limited :)
Re: st.c update has broken dump multi-tape support
Hi Frank, On Thu, Jun 10, 2021 at 07:45:25AM +0200, Frank Kardel wrote: > > Could you check whether my suspicion that biodone() may be missing the > ststart1 function in the > It is missing there but is called in ststart if the error is != 0 after the ststart1 call. I was going to update the ststart function to do something very close to what you have done. > I have not tested the patch as my machine with the tapes is remote and has > no remote console > > and I don't want to brick that while being off-site. > That's ok - I can test here without harming anything, the machine the tape drive is attached to has to be booted to windows for $WORK during the day so my testing window is limited :) -- 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"
Re: st.c update has broken dump multi-tape support
Hi Brett,
that was my impression too. Just check that the write return count on
EOM is zero to indicate EOF.
My stab at this would be the attached patch.
Could you check whether my suspicion that biodone() may be missing the
ststart1 function in the
error == 0 case?
I have not tested the patch as my machine with the tapes is remote and
has no remote console
and I don't want to brick that while being off-site.
Frank
On 06/10/21 04:53, Brett Lymn wrote:
Hi Frank,
On Wed, Jun 09, 2021 at 07:06:07PM +0200, Frank Kardel wrote:
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
Yes, I think you are correct looking at that change. My backup script
does set the early warning flag. I will have a stab at fixing this
later today, I think if I just avoid returning EIO in the ST_EOM_PENDING
case inside ststart it should be good.
--- st.c 2021-06-09 18:31:50.860128750 +0200
+++ st.c.240 2021-06-10 07:30:55.828024537 +0200
@@ -1242,6 +1242,7 @@
bp->b_resid = bp->b_bcount;
error = 0;
st->flags &= ~ST_AT_FILEMARK;
+/* XXX missing a biodone() here? */
goto out;
}
}
@@ -1251,7 +1252,13 @@
* yet then we should report it now.
*/
if (st->flags & (ST_EOM_PENDING|ST_EIO_PENDING)) {
- error = EIO;
+ if (st->flags & ST_EIO_PENDING) {
+ error = EIO;
+ } else {
+ error = 0;
+ bp->b_resid = bp->b_bcount;
+ biodone(bp);
+ }
goto out;
}
Re: st.c update has broken dump multi-tape support
Hi Frank, On Wed, Jun 09, 2021 at 07:06:07PM +0200, Frank Kardel wrote: > > 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 > Yes, I think you are correct looking at that change. My backup script does set the early warning flag. I will have a stab at fixing this later today, I think if I just avoid returning EIO in the ST_EOM_PENDING case inside ststart it should be good. -- 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"
Re: st.c update has broken dump multi-tape support
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.
