Dear Maintainer,

While chasing some brasero flaws, in a recent conversation with Thomas
Schmitt, the following trailing padding for TAO tracks was recommended
for the libburnia plugin.

Brasero might rather lure out the Linux read-ahead-bug, at least on systems
which still suffer from it. Squeeze seems to explicitely test for it. So the
TAO track without padding causes command "mount" to need 70 seconds to do its job:
  # time mount /dev/sr1 /mnt
  real    1m10.458s

/var/log/messages then has:
  Jul  9 15:24:58 debian2 kernel: [  606.394637] sr 4:0:0:0: [sr1] Sense Key : Medium Error [current]
  Jul  9 15:24:58 debian2 kernel: [  606.394645] sr 4:0:0:0: [sr1] Add. Sense: L-EC uncorrectable error
  Jul  9 15:24:58 debian2 kernel: [  606.394653] sr 4:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 34 90 00 00 02 00

This READ(10) command tries to read block 13456 (dec) which is the first
non-data one after the end of the track's data blocks.
Mount has nothing to read there. The the last ISO image block is 13455.
So it is probably a workaround in mount, which actually should be in /dev/sr.
Or maybe it is just a greedy disk cache which thinks that 27 MB are best
loaded in one sweep.
But dd is not aware of the real data track end:
  $ dd if=/dev/sr1  of=/dev/null bs=2048
  dd: reading `/dev/sr1': Input/output error
  13456+0 records in


To prevent this, Debian would have to modify Brasero's libburn plugin
so that trailing padding of traditionally 300 kB is added.
It would be about the call(s) of burn_track_define_data().
2.30.3 only has one in ./plugins/libburnia/burn-libburn.c :

     burn_track_define_data (track, 0, 0, 0, mode);

The middle zero would have to be changed to 300*1024.
This is the default value used by cdrskin and xorriso, advised by Joerg
Schilling. Probably the value 300 is an urban legend. But it suffices.
Obviously it is a good in-advance remedy for various bugs of CD readers.

Documentation of burn_track_define_data() from libburn.h:
/** Define the data in a track
        @param t the track to define
        @param offset The lib will write this many 0s before start of data
        @param tail The number of extra 0s to write after data
        @param pad 1 means the lib should pad the last sector with 0s if the
               track isn't exactly sector sized.  (otherwise the lib will
               begin reading from the next track)
        @param mode data format (bitfield)
*/
void burn_track_define_data(struct burn_track *t, int offset, int tail,
                            int pad, int mode);


It cannot harm to set parameter "pad" to 1. But libisofs will anyway
only produce complete sectors of 2048 bytes.
Important is parameter "tail".

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

tag 680989 + moreinfo
thanks

Hello,

Does anybody knows if this bug is still relevant?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680989

Cheers,

Laurent Bigonville

Hi,

Well, at least
https://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libburn.c
calls burn_track_define_data() with 0 tail bytes.
There is no call of iso_write_opts_set_tail_blocks() in any
of the .c files in the plugins/libburnia directory.

So there is no indication for padding at the image end.

To be absolutely sure, one would have to test with a modern
brasero and compare the size of the ISO filesystem with the
size of the image file or media track.


Have a nice day :)

Thomas

forwarded 680989 https://bugzilla.gnome.org/show_bug.cgi?id=737890
thanks

Le Sat, 04 Oct 2014 18:02:52 +0200,
"Thomas Schmitt" <scdbackup@gmx.net> a écrit :
https://bugzilla.gnome.org/show_bug.cgi?id=737890

You too, and thanks for the reply :)

Laurent Bigonville

forwarded 680989 https://gitlab.gnome.org/GNOME/brasero/-/issues/275
tags 680989 - fixed-upstream

The bug has been migrated to GNOME's GitLab instance and was incorrectly tagged as fixed-upstream.

thanks