Hi,

i wrote:
> > Back in 2020 i would quite surely have noticed
> > if that behavior had been shown.

Richmond wrote:
>  lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> VENDOR   MODEL                            SIZE PHY-SEC LOG-SEC
> TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312     512     512
>
> 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux

So this behavior is not new.


> This is a laptop where I rarely use the CD/DVD. Note it is not the same
> computer as was getting errors before, that was debian 11.

I assume that you will see the same result there.
It would explain the block address of the first read attempt and the
log messages about unaligned access.
  kernel: [    9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff 
fc 00 00 02 00
  kernel: [    9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer

If you have some blank optical medium, then try whether the emitter of
the read attempt can be discouraged if the drive is perceived as offering
just one block of 2048 bytes.

----------------------------------------------------------------------

The unresolved riddle is which software began to try reading from the
optical drive after your recent package installations or upgrades.
It might be a different one than the software which does similar read
attempts on piorunz' machine since years.

In any case these softwares inquire the device capacity from systemd or
directly from the kernel. Then they try to read end and start of the
obtained capacity.
There are many motivations to read the start of the device and fewer to
read its end. One reason to read the end is the GPT backup header, which
would sit 512 bytes before the end.
The main GPT header block is at byte 512 of the storage device.
This would explain the next failed read attempt:
  kernel: [    9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00
00 00 00 02 00
I wonder why the caller did not want only 512 or 1024 bytes. The number
of 2 requested blocks cannot come from the read-ahead mechanism of the
Linux block layer.

I would still place my bet on something like blkid, which wants to know
whether there is a partition table. Maybe there was a change about a
customer of libblkid.


Have a nice day :)

Thomas

Reply via email to