Bug#680989: brasero: [libburnia plugin] Use traditional trailing padding of 300kB for TAO tracks

[Thomas Schmitt]

Hi,

since traditionally the padding of 300 kB is added by genisoimage or
mkisofs, i have tested an alternative proposal in burn-libisofs.c.

        iso_write_opts_new (&opts, 2);
        iso_write_opts_set_relaxed_vol_atts(opts, 1);
+       iso_write_opts_set_tail_blocks(opts, 150);

        brasero_job_get_flags (BRASERO_JOB (self), &flags);


It would have the advantage to produce images on disk like the other
ISO 9660 generators, and not to add 300 kB to images which Brasero copies
from hard disk to optical medium.
Success could be checked without the need of a CD burner.
  image=".../brasero.iso"
  e=$(xorriso -indev "$image" \
              -find / -sort_lba -exec report_lba -- \
      | tail -1)
  s=$(xorriso -indev "$image" \
              -toc \
      | grep '^ISO session' | tail -1)
  echo "Data file blocks end before " \
       $(echo "$e" | awk '{print $6 + $8}') blocks
  echo "Image size is               " \
       $(echo "$s" | awk '{print $8}' | sed -e 's/s//') blocks
The size should be larger than the data end by 150 blocks.


The disadvantage is that it is actually not the right place for padding.
(Please excuse my technical stubbornness as upstream. Withing xorriso
 i have decided for padding by libburn. But its mkisofs emulation was
 finally forced to follow the example of mkisofs and genisoimage.)


If you choose this alternative, make sure to link with libisofs >= 0.6.38,
released Sat Oct 23 2010.

Documentation of the proposed call in <libisofs/libisofs.h>:
/**
 * Cause a number of blocks with zero bytes to be written after the payload
 * data, but before the eventual checksum data. Unlike libburn tail padding,
 * these blocks are counted as part of the image and covered by eventual
 * image checksums. 
 * A reason for such padding can be the wish to prevent the Linux read-ahead
 * bug by sacrificial data which still belong to image and Jigdo template.
 * Normally such padding would be the job of the burn program which should know
 * that it is needed with CD write type TAO if Linux read(2) shall be able
 * to read all payload blocks.
 * 150 blocks = 300 kB is the traditional sacrifice to the Linux kernel.
 * @param opts
 *        The option set to be manipulated.
 * @param num_blocks
 *        Number of extra 2 kB blocks to be written.
 * @return
 *        ISO_SUCCESS or error
 *
 * @since 0.6.38
 */
int iso_write_opts_set_tail_blocks(IsoWriteOpts *opts, uint32_t num_blocks);


Have a nice day :)

Thomas