Comment 198 for bug 1886148

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

> Thinking it through, I am happy for us to make this change from MBR to
> GPT.

Me not so much. GPT has that backup at the end of the device. But when
an image is made, the size of the storage device is not known. So after
putting (cloning) the image onto the USB stick, the backup GPT is
misplaced.

So we'd actually need an adjustment step after cloning, although the boot
firmwares don't care for that flaw. But partition editors do.
(Modern versions of program sfdisk fix the problem silently when any
 manipulation of GPT is done. E.g.:
   echo 'name=DATA' | sudo sfdisk -a /dev/sdc
)

But if more machines boot by GPT than by MBR partition table, i can hardly
be against it. Let's see what problems this causes ...

> I do see that the GPT has an extra partition at the end; is this required
> for alignment?

It's the padding against the TAO CD Read-Ahead Bug. This bug is caused by
an ambiguity in SCSI MMC specs about command READ CAPACITY when the last
track ends by two TAO Run-out blocks. About 80 percent of CD capable drives
count them as readable, which they are not for data read command READ(10).

By a cargo cult theory of last century, ISO 9660 producers and most burn
programs add 300 KiB of padding to keep legitimate read operations away
from the dangerous end of the device.
Actually it would have to be the buffer size of Linux when reading ahead
of the block range that is requested by the ISO 9660 filesystem driver.

(If i had a better standing at linux-scsi it would already be fixed for
 single session by testing the last two blocks for readability and
 adjusting the device size perception of the kernel if they are not
 readable by READ(10). I have made me a kernel which does this.)

With ISO images which never end up on a CD you can safely suppress this
padding by xorriso -as mkisofs option

  -no-pad

Even then most CD burn programs will add their own padding by default or
use write type SAO which produces no Run-out blocks.

> I haven't seen such partition entries when using MBR.

With MBR partition table the padding is either counted as part of
partition 1 (old Fedora/Debian/Ubuntu layout) or not marked as partition
(with appended partition).

The reason for that GPT partition is probably in my discussions with
Vladimir Serbinenko when i made xorriso ready for serving under
grub-mkrescue. If we find compelling reasons not to create it, i could
try to suppress this.
(The boot preparation code in libisofs is quite entangled by the many
 variations and little stunts which it accumulated over time.)

Have a nice day :)

Thomas