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

[George Danchev]

Source: brasero
Version: 3.4.1-2
Severity: normal
Tags: upstream patch

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".


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 04_traditional-trailing-padding-300kB-tao-track.patch
Type: text/x-diff
Size: 3685 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120709/4ae5b289/attachment.patch>