[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 <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?
> 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
Main Index |
Thread Index |