Re: About /dev/sr impatience with automatic tray loading
On Monday 10 December 2018 12:46:41 Thomas Schmitt wrote:
> Hi,
>
> i wrote:
> > > A workaround in K3b would be let it retry on error ENOMEDIUM for
> > > about 30 seconds and to only then give up.
>
> Gene Heskett wrote:
> > That ought to be doable, but would that not delay the ready by
> > banging on the drive for a status report during that time? It only
> > has so much cpu power.
>
> No. The drive works on its own after the tray went in (e.g. because
> the kernel sent a START/STOP UNIT command). It inspects the medium
> solely controlled by its built-in firmware.
>
> The kernel or a burn program can only send a command TEST UNIT READY
> from time to time. The answer may be that it is indeed ready for work,
> or that it is still undecided, or that there is a problem like no
> medium or incompatible medium.
>
> Currently the kernel immediately indicates ENOMEDIUM to any userland
> attempt to open the device until finally the drive is done with
> inspecting the medium and found it acceptable.
> Up to 2008 the kernel rather waited a short while and repeated the
> test until the "still undecided" reply was gone or timeout occured.
> Only then it answered to the attempt to open the device from userland.
>
Perhaps that patch could be reverted, and the timeout made say 2 minutes,
by which time the drive should be able to make up its mind that the
media is readable, or that its truly duff because the burn wasn't good,
laser failure or ??
I once did a complex lightscribe label, and apparently wiped out the
laser. The label looked complete, but it never read or wrote another
data side, and I went out to Wally's and bought another $26 drive. Which
is still working well much of a decade later.
> (Exempted are open(2) calls with O_NONBLOCK/O_NDELAY which do not
> check for the drive status. They are for those who want contact to
> the drive, not to the medium on the first hand.)
>
>
> A problem with a waiting loop in K3b would appear if the medium
> vanishes between eject and re-load or has become incompatible by a
> drive mishap. In this case K3b would wait 30 seconds in vain and could
> still not decide whether the drive is stuck or the medium is gone.
> But normally, the medium should still be there and the drive should be
> able to decide within a due time that it is at least recognizable.
>
But the 30 seconds does not appear to be enough "due time", so it fails.
Then a dd run to generate the sha1sum (or some suitable variety of sum)
to verify the burn must be done as 2 separate operations, one to get the
files sum and one to get the drives sum.
That I think we can all agree is a PITA.
> K3b could try to be smart and send own TEST UNIT READY commands to the
> drive. It does more obtrusive things during its own media inspection.
>
>
> Have a nice day :)
>
> Thomas
Thanks & take care, Thomas.
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: