Re: Burning and mounting written BDs

[Kjetil Kjernsmo]

On fredag 29. desember 2023 08:57:17 CET Thomas Schmitt wrote:
> Hi,
> 
> Kjetil Kjernsmo wrote:
> > So, meanwhile, I wrote the 25GB M-disc that I had, and that looked fine.
> > check reading logs is attached, that looked fine too and isn't too big.
> 
> Yeah. That's how a good checkread log should look like.

Good! And whaddya know... I just rebooted the machine on a totally unrelated 
problem (around pam), and when it came back up, the BD mounted without a 
hitch! 

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

I'm looking at the munin graphs I have, and not much has happened. It seems 
the check made many interrupt requests over time, but I guess there's nothing 
special about that.

Early last week, I had the box running a core for a few days doing some 
machine learning, and consequently it heated up a bit, but also nothing 
notable, I would think...

> (Maximum speed was 12x = ~ 54 MB/s. Isn't that terribly loud ?

No idea. The box sits in a rack in my basement, in a "technical room" with 
other noisy things, that's isolated from the rest of the house. ;-)

> If so, you may curb speed by xorriso command -read_speed "6" before the
> -check_media command.)

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

> I actually meant that these commands would perform the eject-load cycle
> at the end of a burn run. But of course it does not harm to perform
> such a cycle later.

Ah, right. Yeah, I did them only after my first attempt to mount had failed.
 
> > root@robin:/dev#   osirrox -indev /dev/sr0 -mount indev auto auto
> > /mnt/test/ ...
> > Mount command: mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=0
> > '/dev/sr0' '/mnt/test/' mount: /mnt/test: wrong fs type, bad option, bad
> > superblock on /dev/sr0, missing codepage or helper program, or other
> > error.
> > 
> >        dmesg(1) may have more information after failed mount system call.
> 
> This is unexpected.
> What does the system log say about the reason for this failure ?

Yeah, so 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

Kind regards,

Kjetil