Re: Burning and mounting written BDs

[Thomas Schmitt]

Hi,

Kjetil Kjernsmo wrote:
>  I just rebooted the machine on a totally unrelated
> problem (around pam), and when it came back up, the BD mounted without a
> hitch!

Strange.


> I don't have the dmesg anymore, as I rebooted, and I don't have the
> timestamp, but I think I matched it in kern.log, I think this is what I saw:
>
> 2023-12-27T00:49:06.631449+01:00 robin kernel: [4685133.115719]
> isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16

This human readable date and log timestamp looks too near to the time
of your first reported mount failure:

> > [4683501.642523] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, 
> > block=16

The difference is only 1632 seconds. So i don't think that this is from
the attempt to mount the 25 GB medium of your second burn run.

If the refusal to mount happens again, please check the system log for
related messages. Check if lines surrounding the "isofs_fill_super" line
might possibly provide more details about the error.

Example, provoked by the attempt to mount an audio CD:

[...] sr 2:0:0:0: [sr0]
[...] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[...] sr 2:0:0:0: [sr0]
[...] Sense Key : Illegal Request [current]
[...] Info fld=0x0, ILI
[...] sr 2:0:0:0: [sr0]
[...] Add. Sense: Illegal mode for this track
[...] sr 2:0:0:0: [sr0] CDB:
[...] Read(10): 28 00 00 00 00 00 00 00 02 00

This does not tell the received SCSI error code. But the texts "Illegal
Request" and "Illegal mode for this track" are listed in SCSI specs as
meaning of sense code [5 64 00].
The line under "CDB:" shows the attempted SCSI command. In this case it
was the request to read two data blocks from block address 0. It failed
because at this address are two audio blocks which would be readable only
by SCSI command READ CD.


> I usually only have downtime when doing a kernel upgrade... Perhaps the box
> needed some ... rest? :-)

If so then it would be no general problem of Linux. My /var/log/messages
shows currently nearly ten times your uptime: [44669411.147860].


> Even though the noise is not a concern, perhaps I should throttle it a bit
> for stability?

I regularly fear about the health of my drives when they go to full
reading speed.
(Especially my Pioneer BDR-S09 drive is willing to spin the medium so fast
that currently sold "Verbatim" branded BD-RE media get cracks at the inner
hole after about ten full-speed full-size readings. Because this drive
does not obey SCSI read speed settings i had to invent a -read_speed mode
named "soft_force" which causes xorriso to slow down the frequency of its
read requests in order to enforce a lower speed.)


I wote:
> > I actually meant that these commands would perform the eject-load cycle
> > at the end of a burn run.

> I did them only after my first attempt to mount had failed.

Just for the records:
It does not matter how and why the tray gets ejected and then reloaded.
Software commands or manual button pressing have the same effect.
It is just about getting  an opportunity to load the medium again into the
drive which will trigger the kernel's inspection of the medium state.

(For hard disk devices there is ioctl(BLKRRPART) to re-assess the
formatted size and partitioning. But this ioctl bails out on sr devices
and there is no alternative for the sr or sg device classes.)

(The reason why growisofs ejects and reloads by default is in its way to
load the ISO metadata for the next session. It uses POSIX I/O via the
kernel's block device layer. Thus it has to make sure that the kernel
knows the new medium state.
libburn on the other hand uses SCSI commands to get its own assessment
of the medium. So xorriso can load the ISO metadata even if the kernel
believes that the medium is still blank.)


> It seems
> the check made many interrupt requests over time, but I guess there's
> nothing special about that.

Dunno. libburn composes SCSI commands (in this case READ(10)) and sends
them to the kernel by ioctl(SG_IO). The lower level of drivers transmits
this command to the drive and awaits the reply. Then the kernel forwards
the obtained data or the failure diagnostics ("Sense Code") back to
libburn.
It may well be that the kernel's waiting is ended by interrupts.


Have a nice day :)

Thomas