[Pkg-libburnia-devel] Bug#567056: brasero: Brasero is very slow burning a data DVD-R
scdbackup at gmx.net
Sat Jan 30 11:24:44 UTC 2010
> > --enable-dvd-obs-64k
> > or
> > --enable-track-src-odirect
> I'm not actually sure whether these options would affect the rest of the
> drives and use cases in an unpredicted way. If they are safe, I'm more than
> happy to enable them in the next package upload, so that the library users
> would benefit as well.
Currently i know of no hard reason not to use
64k blocks on output. The size of growisofs is
32k nevertheless, and libburn is most tested with
The reason for slow drives is not really idenfied
yet. 64k helped in some situations and had no
visible effect in others.
O_DIRECT is an obscure modification of i/o.
Input in this case, not output to drive.
The kernel people hate it:
But Andy Polyakov, the author of growisofs is
much in favor of using it.
It is supposed to take workload from the system.
Normally i follow the kernel advise. It had not
much of a positive effect in my own tries.
But i never heard of a drive that would do as
slow as 2.6x under DMA.
So in this case it might be worth a try.
> Okay, however, the reporter said the speed was fine with growisofs, so if it
> was a DMA settings it would also affect growisofs burning job.
I know that DMA gets disabled if the system
drivers encounter certain errors with the
One should run (as superuser)
hdparm -d /dev/hda | fgrep using_dma
which would reply
using_dma = 1 (on)
using_dma = 0 (off)
To be done before and after the burn runs.
One may (re-)enable DMA by
hdparm -d1 /dev/hda
> Leandro, testing with cdrskin and xorriso and these options (see man for
I would propose to use DVD-R in dummy mode, so
we waste no media and can test high speed.
(Not DVD+R[W]. They cannot do dummy.)
cdrskin is supposed to have been installed
together with libburn.
A test run could be this pipe:
dd if=/dev/zero bs=1M count=4400 | \
cdrskin -vvv dev=/dev/hda -dummy - 2>&1 | \
tee -i /tmp/cdrskin_log
I would be interested in the file
It will be about 250kB of size. Be invited to
send it to me directly:
scdbackup at gmx dot net
To view it yourself:
sed -e 's/\r/\n/g' < /tmp/cdrskin_log | less
See how one of my USB burners goes slow.
Obviously its buffer fill "[buf xx%]" gets
low at about 12x speed which causes short speed
slumps and finally lets the drive reduce to 8x:
Track 01: 1549 MB written (fifo 80%) [buf 92%] 11.5x.
Track 01: 1550 MB written (fifo 79%) [buf 92%] 10.8x.
Track 01: 1551 MB written (fifo 79%) [buf 92%] 11.8x.
Track 01: 1631 MB written (fifo 78%) [buf 61%] 11.8x.
Track 01: 1632 MB written (fifo 79%) [buf 62%] 11.5x.
Track 01: 1633 MB written (fifo 79%) [buf 62%] 11.8x.
Track 01: 1713 MB written (fifo 78%) [buf 14%] 11.8x.
Track 01: 1714 MB written (fifo 77%) [buf 14%] 11.4x.
Track 01: 1715 MB written (fifo 78%) [buf 14%] 11.5x.
Track 01: 2366 MB written (fifo 79%) [buf 46%] 11.5x.
Track 01: 2367 MB written (fifo 79%) [buf 46%] 11.8x.
Track 01: 2368 MB written (fifo 85%) [buf 100%] 0.2x.
Track 01: 2369 MB written (fifo 86%) [buf 100%] 7.9x.
Track 01: 2370 MB written (fifo 86%) [buf 98%] 7.9x.
Track 01: 2371 MB written (fifo 86%) [buf 98%] 8.1x.
Now the drive decided that 8x is the speed to
use. This is an LG. Pioneer drives try full
speed up to the end.
Well, given the low speed in the bug report, real
burns on 4x DVD+RW would be no waste and should
already show slowliness.
> Leandro, could you please tell us whether libburn was actually used for
> burning and which version it was.
Maybe Josselin can answer the question whether
libburn was really in charge. At least he flatly
The installed libburn version can be inquired by
cdrskin -version | fgrep 'libburn in use'
Have a nice day :)
More information about the Pkg-libburnia-devel