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
Description: Use traditional trailing padding of 300kB for TAO track 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". Author: Thomas Schmitt <scdbac...@gmx.net> Bug-Debian: http://bugs.debian.org/679311 --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: <vendor|upstream|other>, <url of original patch> Bug: <url in upstream bugtracker> Bug-Debian: http://bugs.debian.org/<bugnumber> Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber> Forwarded: <no|not-needed|url proving that it has been forwarded> Reviewed-By: George Danchev <danc...@spnet.net> Last-Update: 2012-07-10 --- brasero-3.4.1.orig/plugins/libburnia/burn-libburn.c +++ brasero-3.4.1/plugins/libburnia/burn-libburn.c @@ -267,7 +267,7 @@ brasero_libburn_add_fd_track (struct bur BraseroBurnResult result; track = burn_track_create (); - burn_track_define_data (track, 0, 0, 0, mode); + burn_track_define_data (track, 0, 300*1024, 0, mode); src = brasero_libburn_create_fd_source (fd, size, pvd); result = brasero_libburn_add_track (session, track, src, mode, error);