Re: hfsprogs: Removal of sys/sysctl.h

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

Hi,

Jeroen Diederen wrote:
> kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request
> kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for
> this track
> ...
> kernel: [timestamp] attempt to access beyond end device
> kernel: [timestamp] sr0: rw=0, want 640412, limit 640408

This could be the TAO CD readahead bug with a drive which cooperates
badly with an obscure remedy in the kernel.
Preconditions for the bug are:
- CD-R or CD-RW medium, not DVD, not BD.
- Write type was Track-At-Once (which is default with cdrecord and wodim).

The remedy, which only works beginning with the next read attempt, can be
seen in
  https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
under the false statement
  * The SCSI specification allows for the value
  * returned by READ CAPACITY to be up to 75 2K
  * sectors past the last readable block.
If it works well, then it reduces the registered size of the medium
(ioctl(BLKGETSIZE), lsblk -o SIZE) by 4 KiB. It is know to work better
if the number of 2K blocks of the readable range is divisible by 2.

In our case we have 160103 2K blocks and it looks like overcorrection:

debian-10.0.0-powerpc-NETINST-1.iso of yesterday (2020110715225600)
has 327890944 bytes i.e. 640412 blocks of 512 bytes.
So above "want" is already beyond the end of the ISO but "limit" is inside.
"want" would match the initial perception mistake of the kernel, which
would be with the TAO bug 640416 or 640420 blocks, and an overshooting
correction to 640408 blocks.
The read access to the very end usually happens when software lookings
for a GPT backup block or for an UDF anchor block.


There are various rumors around this bug, but mine is provable and backed
by more optical drives than the others' together. >:]

Normally it gets circumvented by a adding 300 KiB of padding at the end of
the CD track. If my theory is right, then no padding was added to this CD.
How exactly did you burn the it ?

If the burn software offers write type Session-At-Once (SAO) then burn
again using this option.

E.g. xorriso with explicit SAO (it uses it by default if possible)
and padding:

  xorriso -as cdrecord \
              -v dev=/dev/sr0 blank=as_needed -eject padsize=300k \
              -sao debian-10.0.0-powerpc-NETINST-1.iso

The padding might lead to success even if my theory is wrong, because if
the drive would systematically underestimate SAO CDs, then the padding
would sacrifice itself to the mistake like a zinc anode does to salt water.

So in case of success, it would be interesting to see whether a CD burnt
without option
  padsize=300k
is mountable too, and whether a CD burnt by TAO without padding fails:

  xorriso -as cdrecord \
              -v dev=/dev/sr0 blank=as_needed -eject \
              -tao debian-10.0.0-powerpc-NETINST-1.iso

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

If this all turns out to be really the old readahed bug, does anybody here
have enough reputation in linux-scsi to get a fix committed, which i have
ready as set of
  [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO track
  [PATCH 1/3] cdrom: export cdrom_mmc3_profile()
  [PATCH 2/3] sr: provide a test for readability of sectors as data blocks
  [PATCH 3/3] sr: detect CD TAO Run-out blocks and correct device capacity
              if needed
Currently based on 5.9-rc2. Works fine with various drives.
Lengthy cover letter and commit messages. Like this mail. Sorry for that.


Have a nice day :)

Thomas