Hi, > > --enable-dvd-obs-64k > > or > > --enable-track-src-odirect > Thomas, > 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 32k. 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: http://kerneltrap.org/node/7563 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 drive. One should run (as superuser) hdparm -d /dev/hda | fgrep using_dma which would reply using_dma = 1 (on) or 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 > examples) 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 /tmp/cdrskin_log afterwards. 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 assumed it. The installed libburn version can be inquired by cdrskin -version | fgrep 'libburn in use' Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org