Re: [PATCH v2 1/2] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN

[Laurence Oberman <loberman@redhat.com>]

On Tue, 2026-09-29 at 17:15 +0300, Kai Mäkisara (Kolumbus) wrote:
> 
> 
> > On 28. Sep 2026, at 16.25, Laurence Oberman <loberman@redhat.com>
> > wrote:
> > 
> > A device reset returns the drive's density and block size to their
> > defaults.  Commit 7081dc75df79 ("scsi: st: Restore some drive
> > settings
> > after reset") re-applies values changed by the user when the
> > position is
> > recovered with MTREW, MTSEEK or MTEOM.  MTLOAD and MTRETEN are also
> > allowed to clear the reset condition and also leave the same medium
> > at
> > BOT, but they restore nothing.
> > 
> > Because check_tape() reads the drive's block size with MODE SENSE
> > on
> > every open, the driver silently switches to the drive default after
> > the
> > reset.  An application that set fixed-block mode with MTSETBLK and
> > recovers with MTLOAD or MTRETEN keeps writing, but variable-length
> > blocks, without any error.
> 
> Reset also returns the drive buffering mode (STp->drv_buffer) to the
> default.
> This should also be restored. It might be possible to use the same
> logic than
> with density and block size. check_tape() reads the possibly damaged
> drv_buffer
> value. So the old value should be saved before check_tape() and
> restored if
> the value after check_tape() differs from the saved value (and the
> saved
> value != 1). (I may have overlooked somthing.)
> 
> Another thing is the auto_lock mode. It should be enough to set
> STp->door_locked = ST_UNLOCKED when reset is recognized. The door
> wiil
> then be locked at first read or write.
> 
> Otherwise I did not find any issues.
> 
> Thanks, Kai
> 
> 
Thanks Kai. Both are new patches in v3: 3/4 records the buffering mode
set with MTSETDRVBUFFER and restores it in both restore paths (it is
already lost when the device is reopened after the reset, so it is
saved when set rather than before check_tape()), and 4/4 sets
door_locked = ST_UNLOCKED when the reset is recognized. Both reproduced
and verified on an IBM LTO-5.