[Pkg-libburnia-devel] Large size penalty from -isohybrid-mbr and -partition_offset 16?

[Thomas Schmitt]

Hi,

the reason for the miscalculation of image size alignment should
now be fixed by the single-line changeset:
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/862

Freshly uploaded is a GNU xorriso development snapshot:
  http://scdbackup.sourceforge.net/xorriso-1.0.9.tar.gz

I tested with default padding (300 kB), with option -no-pad, and
with a padding of 3500 kB (just to try something unusual).
All three images emerged with an integer size of MB, which silences
these fdisk complaints:
  Partition 1 has different physical/logical beginnings (non-Linux?):
  Partition 1 has different physical/logical endings:

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


Colin Watson:
> I tried -no-pad and it has only negligible effect on size,
> though; 693415936 -> 693108736 bytes.

Now it is aligned to a full MB, which is the default cylinder size for
images up to 1023 MB.


> Would you recommend -no-pad in general?  I'd rather not have to give out
> specialised burning instructions.

300 kB is a very traditional remedy for a very traditional Linux bug.
Both are so old that any change could break something somewhere else. :))

We should stay with it, unless there is the need to use the last 300 kB
on media.


> it looks like creating
> hybrid images should now not be a problem for us.

Are there large uncompressed files which shall only be read by Linux
(and not by the boot system) ?
In that case consider zisofs compression.
It needs zlib at xorriso build time and CONFIG_ZISOFS with the reading
Linux kernel.

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


The Linux TAO Read Ahead Bug actually depends on the size a system buffer.
It happens somewhere between libc and SG_IO. On my aged kernel most probably
underneath
  /usr/src/linux/block/scsi_ioctl.c

The problem is about MMC commands which report the size of a CD track
(READ TRACK INFORMATION or READ TOC/PMA/ATIP).
Their size reply includes two non-data blocks if the track was written
in mode TAO.
The device driver gets lured into reading these blocks. This yields an
SCSI error condition. Obviously the device driver does not try
to read again those blocks which would be good but were in the range of
the failed attempt.

After some fgrepping, my favorite suspect would be:
  /usr/src/linux/block/ll_rw_blk.c:
  q->backing_dev_info.ra_pages = (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
  /usr/include/linux/mm.h:
  #define VM_MAX_READAHEAD        128     /* kbytes */

So 126 kB would be a sufficient padding, if my theory is right.
The size of 300 kB is probably a historical misunderstanding of the
reason. It is actually the mandatory gap between two TAO tracks.

Write mode TAO is default at least with older cdrecord versions.
It is the one which does not need to know the track size in advance.
So even modern burn programs will employ TAO if a pipe provides the
input data stream.


Have a nice day :)

Thomas