[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upcomming trouble with Sid kernel and TAO CDs


how much is debian-cd concerned/interested that CDs written by write type
TAO stay readable for e.g. blkid ?

I ask because Archlinux ISOs already do not boot properly from such CDs
as they rely on /dev/disk/by-label/ links to mount the ISO.

The current amd64 mini.iso would suffer the same fate, if it did rely
on blkid for booting. I burned it to a CD-RW with option -tao and
booted it on real iron to rescue mode (without mounted root).

Same symptoms as with Archlinux:
- blkid does not work with /dev/sr0. dmesg shows i/o errors,
  both at the first TAO run-out block.
- dd reports one i/o error at some random sector near the end,
  and one i/o error at the first TAO run-out block.

On Archlinux uname says 4.3.3-3, on Debian it says 4.3.0-1.
So we are up to reports about strange behavior of some netinst CDs
as soon as kernel 4.3 hits the users.

If there is interest i could need help in understanding the block
device procedures which distinguish 4.3 from 3.16. A few months ago
i was glad to read in /usr/src/linux-{3.16,4.1.6}/drivers/scsi/sr.c
a quite mislead comment and remedy, which nevertheless causes nearly
flawless behavior in 3.16.
         * The SCSI specification allows for the value
         * returned by READ CAPACITY to be up to 75 2K
         * sectors past the last readable block.
         * Therefore, if we hit a medium error within the
         * last 75 2K sectors, we decrease the saved size
         * value.
It is actually about the last 2 sectors. The number 75 is unrelated
and probably a schily rumor. (I dare the world to show me that specs part.)
I also wonder where the SCSI specs promise this info:
       error_sector = (SCpnt->sense_buffer[3] << 24) |
                (SCpnt->sense_buffer[4] << 16) |
                (SCpnt->sense_buffer[5] << 8) |
which seems to work the miracle of exact read amount in 3.16.
Is this artificial info from the drivers ?

Something must have changed with buffering and reading-ahead which
now devalues this effort. Maybe it's even about the miracle sense data.

If there is no interest in the kernel problem, then we should at least
begin to warn of TAO CD recording. Obviously Brasero does it by default.
Afaik, wodim does it by default.

Have a nice day :)


Reply to: