About /dev/sr impatience with automatic tray loading

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

Hi,

i'm starting this spin-off thread to avoid pollution of
  "dd: error reading '/dev/sr0': Input/output error"

I wrote:
> ... > (We have a bug in the kernel since 2008 which prevents waiting for
> ... > the drive to become ready after automatic tray loading.
> > The old timeout limit was 20 seconds. [...] So i'd propose 30 seconds

Gene Heskett wrote:
> I personally think thats a heck of a good idea. Someone with commit 
> rights should make it so.

First the consequences of commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734
need to be repaired. (I'd propose in drivers/cdrom/cdrom.c a dedicated
function named wait_for_medium_decision() to be called from existing
function open_for_data() instead of calling cdo->drive_status() directly.)

It's not about commit permission. It's about the well plausible rules laid
out at
  https://kernelnewbies.org/FoundBug
in paragraph "Has your bug been fixed ?". I need a newish kernel to prove
that the bug is still there and to test my proposed fix. (I tested that
it compiles and does not explode on a Sid VM with a virtual CD-ROM.)
The nature of the affected kernel module makes it necessary to develop
and test on real hardware. (My host /dev/sr4 always shows up as /dev/vda
on the VM if i try to forward it by virtio.)

Only then i could begin to beg for the attention of empowered people who
are willing to fix bugs which were planted by co-workers in an act of
drive-by programming. (One could have tested, back in 2008, instead of
making the failure look more plausible by commit
96bcc722c47d07b6fd05c9d0cb3ab8ea5574c5b1.)


> The best cd/dvd writer we have, k3b,

Cough. It is a frontend to burn programs like wodim, growisofs, cdrskin,
and maybe libburn, meanwhile. It also contains copied body parts of
such programs for doing its own media inspection.
Insofar it cannot be better at the core task of burning than its backend.


> cannot be told to verify its written 
> image because it times out way too fast at re-recognizing the ejected 
> and reloaded disk.  This has needed fixing since years ago.

Problem is that GUI programmers come and go.


Jude DaShiell wrote:
> > Why not prefix that dd command with a sudo udevadm settle command and
> > only allow the dd command to run on success case?

Gene Heskett wrote:
> Perhaps there is a place to configure that into k3b, and make a write 
> verify work?

The udev event queue is not involved in the kernel's perception of the
medium state. Currently the cdrom code does not wait for the drive to
indicate its readiness and thus emits error ENOMEDIUM as long as the drive
is still inspecting the freshly loaded medium.


I wrote:
> > I use:
> >   xorriso -outdev /dev/sr0
> > before trying to read the medium by POSIX i/o like dd(1) or read(2).

Gene Heskett wrote:
> This is also something that has not been installed till now, and has more 
> buttons than grandma's button jar.

But you don't need K3b to get your backup stuff done.

> But could it be configured into k3b for automatic usage?

We would have to find out why K3b fails. Did it eject the tray and re-load
it, before it tried to verify ?

If not, then it does not suffer from above kernel bug, but rather from
something else.

If the tray moved out and in, then it tries to work around the problem
of mixing POSIX i/o with writing via ioctl(SG_IO) by the burn backend.
Only tray loading forces the kernel to re-assess the new medium content.
(It would only need a small change in ioctl(BLKRRPART) to let it re-assess
 the content of a /dev/sr before bailing out because there is no partition
 table supposed to be assessed on /dev/sr. Like:
   https://www.spinics.net/lists/linux-block/msg22999.html
)
A workaround in K3b would be let it retry on error ENOMEDIUM for about
30 seconds and to only then give up.


Have a nice day :)

Thomas