Re: About /dev/sr impatience with automatic tray loading

["Thomas Schmitt" <scdbackup@gmx.net>]

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.

(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.

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