Packet writing extremely slow
Hello
I've set up packet writing, and it seems to work, the data can be
re-read correctly, but writing is extremely slow.
Kernel: 2.6.8.1, packet-2.6.8-2 patch, UDF write caching enabled
patched udftools
LG GSA-4120B DVD writer
using UDF file system, mounted with noatime
I'm mounting through the packet device /dev/pktcdvd/...
I don't get any suspicious messages in /var/log.
Copying 673 MB in 96 files and directories to an Intenso DVD+RW media
takes 12min 24sec, that's 744 kB/sec. Copying to a Philips 12x CD-RW
instead, I get 844 kB/sec. Yes, it's faster.
Burning the same with k3b (growisofs) takes 4min 20sec, that's 3192
kB/sec.
Copying 201 MB in 3585 files and directories, with packet writing to the
same media takes over an hour, 50 kB/sec (!). Burning to the CD-RW, I
get 32 kB/sec (!).
I assume it isn't supposed to be that slow. :>
I've tried the two patches mentioned in
http://lists.suse.com/archive/packet-writing/2004-Jun/0008.html
(p00002_dvd+rw.patch.bz2, p00003_dvd-rw-packet.patch.bz2), but they
are against 2.6.7, and can't be applied to a 2.6.8 kernel.
Is there any obvious way to fix this? Is packet writing ready yet for
general use? Does this seem like a configuration problem, or isn't my
writer properly supported yet?
Thanks,
Volker
--
Volker Wysk
I assume it isn't supposed to be that slow. :>
A long time ago (1y?) I tried it too, and got about your speed.
Is there any obvious way to fix this?
Pay someone to implement it properly in Linux? (This may conceivably involve fixing some not so easy Linux problems.)
Is packet writing ready yet for general use?
If I can script a block copy of an existing CD to harddisk, loop mounting it, running mkisofs to make a new image, and writing out the new image to CD-RW faster than adding the files with packet writing, my answer is surely "no". AFAIU packet writing is mainly for CD-RW (well on Linux anyway). These don't seem to have a high uptake, I continually come across people who can't be bothered to get some CD-RW for testing when they can waste some CD-R instead. CDs are on the way out anyway, their capacity is too much of a pittance; I don't expect packet writing for CD-RW to advance much beyond the current point. If the same techniques are useful for DVD+RW then maybe, but if the volume of data you want to add is reasonably big (like eg >100MB), it's little waste of space to just add another session. Adding a session gives you no trouble, is well tested and fast. If you need to remove files something like packet writing would be handy indeed, but unless it works properly (and reliably!!) you're again better off to copy the used part of 4.37GB (still tiny) to harddisk and write a new image.
Volker
Volker ;) -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
On Sun, 10 Oct 2004, Volker Kuhlmann wrote:
I assume it isn't supposed to be that slow. :>
A long time ago (1y?) I tried it too, and got about your speed.
Is there any obvious way to fix this?
Pay someone to implement it properly in Linux? (This may conceivably involve fixing some not so easy Linux problems.)
I think the problem is the design that splits the driver into a filesystem part (udf) and a writable block device part (pktcdvd). The udf file system expects the block device to behave as a hard disk (ie reasonable seek times and no penalty for writing 2KB at a time.) The result is that the pktcdvd driver is given an I/O request pattern that is no good for optical media with large seek times and big penalties for 2KB writes. See also these LKML messages: http://marc.theaimsgroup.com/?l=linux-kernel&m=108901564715767&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=108969885605967&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=109437503110244&w=2 For comparison I unzipped the 2.6.8.1 kernel source tree onto a DVD+RW disc in Windows XP using Roxio "drag-to-disc", and the process completed in less than 5 minutes. This shows that it's possible to perform a lot better than the current linux implementation, which required about 1 hour for the same operation. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (3)
-
Peter Osterlund
-
Volker Kuhlmann
-
Volker Wysk