NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: Manuel Bouyer <>
To: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@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?
 > 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 <>
      NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index