Re: kern/55965: st(4) on adaptec fails to 'mt erase'

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/55965; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
Date: Sun, 31 Jan 2021 09:48:53 +0100

 On Sun, Jan 31, 2021 at 12:21:55AM +0100, Hauke Fath wrote:
 > At 23:43 Uhr +0100 30.01.2021, Manuel Bouyer wrote:
 > >Hum. I've not looked at the code but maybe the erase is started and
 > >the ioctl returns. Then mt exists,
 > 
 > "exits", you mean?
 
 Yes.
 
 > No, it doesn't, that is what I am puzzled about.
 > 
 > Naively, I would have expected mt to return, and have a way of checking on
 > the tape if I am curious.
 > 
 > mt sitting there patiently until the drive is finished with the erase is
 > synchronous behaviour in my book.
 
 This is because closing the device cause the call to scsipi_prevent(),
 which waits for the erase to complete.
 exit() does an implicit close, if mt doens't do it itself.
 
 > 
 > > causing the device from being
 > >closed. This causes scsipi_prevent() from being called, and this
 > >command waits for the erase to complete.
 > >
 > >Baybe you should use /dev/ernst0 instead of rst0 ?
 > 
 > You mean "enrst0", AKA control mode? Since I have a tape in the drive to be
 > erased, what should that buy me?
 
 Avoid the call to scsipi_prevent() on close.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --