Wayde Milas wrote:

On Wednesday 17 July 2002 04:09 pm, Ben Fennema wrote: /> Just a though, but try:/ />/ /> dd if=/dev/zero of=/dev/sr0 bs=2048 count=5120/ /> mkudffs /dev/sr0 5120/ />/ /> mount/ /> try and copy stuff/ />/ /> and see if you have any better luck./

Nopers. The create worked, but the same problem when I tried to copy the mkudffs dir over: cp -a mkudffs /mnt/cdrom cp: cannot create directory `/mnt/cdrom/mkudffs': Input/output error

you have of course mounted it as rw?

dmesg: UDF-fs INFO UDF 0.9.6-rw (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/17 19:27 (1ed4) I/O error: dev 0b:00, sector 1096

i have a similar problem, though i am actually able to write what seems to be a random number of MBs for each time i mount the drive. my dmesg at mount: UDF-fs DEBUG ../linux-2.4/lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG ../linux-2.4/super.c:1434:udf_read_super: Multi-session=0 UDF-fs DEBUG ../linux-2.4/super.c:406:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG ../linux-2.4/super.c:766:udf_load_pvoldesc: recording time 1027029029/953030, 2002/07/18 14:50 (1e5c) UDF-fs DEBUG ../linux-2.4/super.c:776:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' UDF-fs DEBUG ../linux-2.4/super.c:783:udf_load_pvoldesc: volSetIdent[] = '3d373825LinuxUDF' UDF-fs DEBUG ../linux-2.4/super.c:975:udf_load_logicalvol: Partition (0:0) type 1 on volume 1 UDF-fs DEBUG ../linux-2.4/super.c:985:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=141, partition=0 UDF-fs DEBUG ../linux-2.4/super.c:813:udf_load_partdesc: Searching map: (0 == 0) UDF-fs DEBUG ../linux-2.4/super.c:854:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0 UDF-fs DEBUG ../linux-2.4/super.c:895:udf_load_partdesc: Partition (0:0 type 1511) starts at physical 274, block length 2294573 UDF-fs DEBUG ../linux-2.4/super.c:1228:udf_load_partition: Using anchor in block 256 UDF-fs DEBUG ../linux-2.4/super.c:1461:udf_read_super: Lastblock=0 UDF-fs DEBUG ../linux-2.4/super.c:738:udf_find_fileset: Fileset at block=141, partition=0 UDF-fs DEBUG ../linux-2.4/super.c:799:udf_load_fileset: Rootdir at block=143, partition=0 UDF-fs INFO UDF 0.9.6 (2002/03/14) Mounting volume 'LinuxUDF', timestamp 2002/07/18 14:50 (1e5c) -- i the try to copy a 500MB file onto the disk: # cp -i cd3.iso /mnt/dvd+rw/ cp: /mnt/dvd+rw/cd3.iso: No space left on device # my dmesg at this point is: I/O error: dev 0b:00, sector 1108 I/O error: dev 0b:00, sector 1108 the size of the file written to the disk is ~99MB. if i now unmount the drive and remount it, i can write some additional bytes to it. For each time i do this, the lost+found directory appears and disappears on an apparently random basis. :( gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com www.bresystems.com "My goal is to make any information available from anywhere, at anytime."

I know for me the background format is definately complete.... and the dd thingy doesnt help.

Out of curiosity, is the background format complete when you try and mount the disc, or is it ongoing? (maybe every time you mount/umount the disc, more of it has been formated so you can use more...)

If you say, dd if=/dev/zero of=/dev/sr0 bs=2048 count=(however many blocks on the dvd+rw), then run mkudffs and mount it, can you write the whole file right away?

Ben

Wayde

On Thursday 18 July 2002 09:36 pm, Ben Fennema wrote:

On Thu, Jul 18, 2002 at 08:59:47PM -0500, Wayde Milas wrote:

...

I know for me the background format is definately complete.... and the dd thingy doesnt help.

Out of curiosity, are you using a newer +R compatible drive, or the older +RW only drive? (As far as I know, their all rebranded Ricoh drives)

Latest firmware?

Ben

I'm using a Sony DRU-120A. As far as i know its a new device (Just bought it new off of googlegear.com last month) It reads and writes DVD +R. As far as the firmware, how would i check it? hdparm or soemthing (Cant test it right now cause its sitting at home :) -- Wayde Milas Rarcoa (630) 654-2580

On Friday 19 July 2002 09:57 am, Rene Bartsch wrote:

Am Fre, 2002-07-19 um 16.25 schrieb Wayde Milas:

...

On Thursday 18 July 2002 09:36 pm, Ben Fennema wrote:

...

On Thu, Jul 18, 2002 at 08:59:47PM -0500, Wayde Milas wrote:

...

I know for me the background format is definately complete.... and the dd thingy doesnt help.

Out of curiosity, are you using a newer +R compatible drive, or the older +RW only drive? (As far as I know, their all rebranded Ricoh drives)

Latest firmware?

Ben

I'm using a Sony DRU-120A. As far as i know its a new device (Just bought it new off of googlegear.com last month) It reads and writes DVD +R.

As far as the firmware, how would i check it? hdparm or soemthing (Cant test it right now cause its sitting at home :)

You should get the revision from BIOS when booting or with "hdparm -I /dev/hdX".

With Sony you have a firmware-problem. They do not provide new ones. Only registered dealers of Sony do the updates, which are free while warranty and are to be paid after warranty is over. You need to send in your writer for some days or weeks (That's why I won't buy Sony again).

Rene

I understand I may have a firmware problem if the bios is old, and now I understand that i cant update it, but per my previous post, I'm not even aware if its actually possible to create a udf filesystem on a dvd rw then mount it read write in linux. If it is, I'll persue the bios update farther. Wayde

On Friday 19 July 2002 10:09 am, Sergiy Kudryk wrote:

--- Wayde Milas wrote:

...

On Thursday 18 July 2002 09:36 pm, Ben Fennema wrote:

...

On Thu, Jul 18, 2002 at 08:59:47PM -0500, Wayde Milas wrote:

...

I know for me the background format is definately complete.... and the dd thingy doesnt help.

Out of curiosity, are you using a newer +R compatible drive, or the older +RW only drive? (As far as I know, their all rebranded Ricoh drives)

Latest firmware?

Ben

I'm using a Sony DRU-120A. As far as i know its a new device (Just bought it new off of googlegear.com last month) It reads and writes DVD +R.

As far as the firmware, how would i check it? hdparm or soemthing (Cant test it right now cause its sitting at home :)

Maybe it's bug in your drive firmware (microcode)..

Check for firmware updates for your model at next page :

http://sony.storagesupport.com/dvdrw/dru120a_dwn.htm

Also take attention that only CDRW drives (not all vendors) fully supported under Linux in packet writing mode.

Yes, Im aware that the packet interface is only aplicable to cd rw devices.. this whole thread started cause i was not aware that dvd rw are not packet devices. I realize this now :P However, I'm still a bit confused as to whether there is any way to write a udf or ext2 file system without first creating a loppback device, making the file system on it, then burning the whole big file in one shot with a dd on a dvd rw. Wayde

On Fri, Jul 19, 2002 at 08:22:31PM -0500, Wayde Milas wrote:

Yes, Im aware that the packet interface is only aplicable to cd rw devices.. this whole thread started cause i was not aware that dvd rw are not packet devices. I realize this now :P

However, I'm still a bit confused as to whether there is any way to write a udf or ext2 file system without first creating a loppback device, making the file system on it, then burning the whole big file in one shot with a dd on a dvd rw.

It should work =] for various firmware updates, see http://perso.club-internet.fr/farzeno/firmware/dvd/dvdrf.htm So what firmware version do you have? Ben

On Sat, Jul 20, 2002 at 08:04:00AM -0500, Wayde Milas wrote:

Model=SONY DVD+RW DRU-120A, FwRev=1.13, SerialNo=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Looking at that bios update page, it looks like its the most current bios :P

Have you tried writing to it via ide-cd vs ide-scsi? Ben

Ben Fennema wrote:

On Wed, Jul 17, 2002 at 03:02:02PM -0700, guStaVo ZaeRa wrote:

...

Wayde Milas wrote:

...

On Wednesday 17 July 2002 04:09 pm, Ben Fennema wrote: /> Just a though, but try:/ />/ /> dd if=/dev/zero of=/dev/sr0 bs=2048 count=5120/ /> mkudffs /dev/sr0 5120/ />/ /> mount/ /> try and copy stuff/ />/ /> and see if you have any better luck./

Nopers. The create worked, but the same problem when I tried to copy the mkudffs dir over: cp -a mkudffs /mnt/cdrom cp: cannot create directory `/mnt/cdrom/mkudffs': Input/output error

you have of course mounted it as rw?

...

dmesg: UDF-fs INFO UDF 0.9.6-rw (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/17 19:27 (1ed4) I/O error: dev 0b:00, sector 1096

i have a similar problem, though i am actually able to write what seems to be a random number of MBs for each time i mount the drive.

-- i the try to copy a 500MB file onto the disk:

# cp -i cd3.iso /mnt/dvd+rw/ cp: /mnt/dvd+rw/cd3.iso: No space left on device #

my dmesg at this point is: I/O error: dev 0b:00, sector 1108 I/O error: dev 0b:00, sector 1108

the size of the file written to the disk is ~99MB.

if i now unmount the drive and remount it, i can write some additional bytes to it. For each time i do this, the lost+found directory appears and disappears on an apparently random basis.

Out of curiosity, is the background format complete when you try and mount the disc, or is it ongoing? (maybe every time you mount/umount the disc, more of it has been formated so you can use more...)

i am pretty sure that it's all done. the formatting only takes a couple of seconds, right? this is the output: [root@ksi2 compile]# mkudffs --media-type=cdrw /dev/cdrom start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=31, type=USPACE start=288, blocks=32, type=PVDS start=320, blocks=32, type=LVID start=352, blocks=32, type=STABLE start=384, blocks=1024, type=SSPACE start=1408, blocks=2293408, type=PSPACE start=2294816, blocks=31, type=USPACE start=2294847, blocks=1, type=ANCHOR start=2294848, blocks=160, type=USPACE start=2295008, blocks=32, type=STABLE start=2295040, blocks=32, type=RVDS start=2295072, blocks=31, type=USPACE start=2295103, blocks=1, type=ANCHOR

If you say, dd if=/dev/zero of=/dev/sr0 bs=2048 count=(however many blocks on the dvd+rw),

a question that might seem a little naive: how do i know the amount of blocks on the disk?

then run mkudffs and mount it, can you write the whole file right away?

i don't know yet. gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."

On Thu, Jul 18, 2002 at 11:31:21PM +0200, Peter Osterlund wrote:

On Wed, 17 Jul 2002, Sergiy Kudryk wrote:

...

Is it possible to exclude mixed write/read operations with pktcdvd ?

For example when i move multiple small files from CDRW disk to harddrive mixed read /write transactions occurs. This degrades overall performance and potentially can destroy laser head of CDRW drive.

Can be in pktcdvd code implemented mechanism similar to semaphore: stop write transactions when we have read one and contra ?

This is what I wrote in an earlier mail:

I think the speed issue is caused by two things:

The udf filesystem seems to be inefficient at handling many small files. I don't know if that's caused by the current implementation or by something in the udf specification that requires such behavior.

The pktcdvd module is bypassing the the I/O elevator when creating write requests for the CDRW drive. This can make performance really suffer when there is a mixed read/write load. The 2.5 version of pktcdvd has fixed this problem, but a backport is not easy because it relies heavily on the new bio infrastructure in 2.5.

I still think that's true, but I have some more information on the udf filesystem behavior. If I create a new udf filesystem and start adding lots of small files to it, at first (before dirty data writeback starts) the speed at which files are added is limited by how fast data can be *read* from the CD. I haven't looked at the udf code yet, but I would guess the udf filesystem reads a disk block for each file being added.

Hmm, it could be an issue with data being embedded in the inode. The data would go through the page cache, but the inode would go through the buffer cache, and this could force a read or something funky like that. Mounting with -o noadinicb turns off this behavior. You could try it and see if it eliminates the extra reads. Ben

On Fri, Jul 19, 2002 at 01:33:13PM +0200, Peter Osterlund wrote:

On Thu, 18 Jul 2002, Ben Fennema wrote:

...

On Thu, Jul 18, 2002 at 11:31:21PM +0200, Peter Osterlund wrote:

...

I still think that's true, but I have some more information on the udf filesystem behavior. If I create a new udf filesystem and start adding lots of small files to it, at first (before dirty data writeback starts) the speed at which files are added is limited by how fast data can be *read* from the CD. I haven't looked at the udf code yet, but I would guess the udf filesystem reads a disk block for each file being added.

Hmm, it could be an issue with data being embedded in the inode. The data would go through the page cache, but the inode would go through the buffer cache, and this could force a read or something funky like that.

Mounting with -o noadinicb turns off this behavior. You could try it and see if it eliminates the extra reads.

There are still reads. I'm not sure if it's exactly the same amount of reads, but I didn't notice any difference in performance.

(But maybe you already know what the problem is. I got that impression from your other mail.)

Ok, here's a patch which should fix the problem. Let me know if it shows a noticeable improvement (or if you can't get it to apply nicely to whatever kernel version your using) =] It's against the 2.4 cvs tree, and prolly only works on 2.4.18+ (since all the version checks got ripped out of the code, which is actually makes the patch as large as it is) Ben

On Sat, 20 Jul 2002, Chris Clayton wrote:

I too have applied Ben's patches and the time taken to write the kernel sources to a CDRW on a 32x12x40 burner has reduced dramatically (from > 50 minutes to < 5). Good work.

But something else appears to have happened as well. For a week or two (and, I freely admit, without really knowing what i am looking for), I have been digging around seeing if I could find what might be causing the file corruption (2048 bytes of 0's) when large numbers of files (like the kernel sources) are written to a packet-formatted CDRW ). Having applied Ben's patches, that problem seems to have gone away too!

I think this is just a happy coincidence. I guess there exists a particular sequence of read/write commands that makes the packet driver confused if the timing is exactly right, and Ben's udf optimization just makes that much less likely to happen. Remember that I saw this corruption also when using the ext2 filesystem. Anyway, investigating this corruption problem is on my todo list. Did you always see only 0's in the corrupted data? I remember I saw pieces from other files and seemingly random data. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

On Saturday 20 July 2002 10:39 pm, Peter Osterlund wrote:

Did you always see only 0's in the corrupted data? I remember I saw pieces from other files and seemingly random data.

Peter, I said I would do some more tests and I have done so. Not sure how much it helps but this is what I observe. Using the test I described in my message yesterday: 17 files were corrupted. In all cases, data had been replaced by 0's. 11 of the files had their first 2048 bytes set to 0 and of these 3 had second chunks of corruption. One, which was 3337 bytes in size, had the remainder of the file also set to 0 (i.e. it was all 0's). the other 2 had their final chunks, one starting at 0x6800 and the other at 0x1800, set to 0's. 5 files had their final chunks, starting at 0x1000, filled with 0's. 1 file had its final chunk, starting at 0x2000, filled with 0's. From these tests it would appear that it is always the first and final chunks of the file which are corrupted and sometimes it's both. The corruption always starts on a 2048 byte boundary, but I think we already knew that. From some notes I have from earlier tests, I can say for sure that different files are corrupted on each test I've kept the hexdumps of the pre and post copied files and the diffs from those hexdumps, and can tar them and put them in some free webspace for retrieval if they would be of any use to anyone. Also, more than happy to try any other tests that might be useful. Regards, Chris

This is what I am doing:

cdrwtool -d /dev/sr0 -q pktsetup /dev/pktcdvd0 /dev/sr0 mount -t udf -o rw,noatime /dev/pktcdvd0 /cdrw cp -r linux /cdrw diff -ar --brief linux /cdrw/linux >> linux.diff

I try to do the same, and get the following errors. could someone tell me what i'm doing wrong? [root@ksi4 /dev]# cdrwtool -d /dev/cdrom -q using device /dev/cdrom 1280KB internal buffer setting write speed to 12x Settings for /dev/cdrom: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/cdrom. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank wait_cmd: Invalid argument Command failed: a1 01 00 00 00 00 00 00 00 00 00 00 - sense 05.30.02 blank disc: Invalid argument -- If I use Andy's dvd formatting tool (dvd+rw-format) 'dvd+rw-format -f /dev/cdrom' I get this: [root@ksi4 /root]# dvd+rw-format -f /dev/cdrom * DVD+RW format utility by , version 2.0. * 4.7GB DVD+RW media detected. * formatting 1.6\ one question: why does the formatting only go to 1.6%? -- if i try to use pktsetup, i get the following error: [root@ksi4 /root]# pktsetup /dev/pktcdvd0 /dev/scd0 ioctl: Inappropriate ioctl for device -- like i've stated before, i've been able to mount the drive as UDF, but unable to copy one large (~500MB) file to the drive. cheers, gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."

...

I try to do the same, and get the following errors. could someone tell me what i'm doing wrong?

[root@ksi4 /dev]# cdrwtool -d /dev/cdrom -q

That only works for CDRW's

oh.. hehe... now i feel a bit silly..

...

If I use Andy's dvd formatting tool (dvd+rw-format) 'dvd+rw-format -f /dev/cdrom' I get this:

[root@ksi4 /root]# dvd+rw-format -f /dev/cdrom * DVD+RW format utility by , version 2.0. * 4.7GB DVD+RW media detected. * formatting 1.6\

one question: why does the formatting only go to 1.6%?

Cause it's supposed to auto extend the format as you write to the disc.

Thats why I suggested dd-ing the whole disc, then trying to mount it and copy the file. Then you'd know the whole disc had been formated, and it wasn't a problem with the format extension.

Ben

I've done as you suggested : dd if=/dev/zero of=/dev/sr0 bs=2048 count=2295104 but since i don't have sr0 in my /dev dir, i assume it's supposed to be scd0. [root@ksi4 /root]# dd if=/dev/zero of=/dev/scd0 bs=2048 count=2295104 dd: /dev/scd0: Read-only file system So then i try to do this : [root@ksi4 /root]# mkudffs --media-type=cdrw /dev/cdrom trying to change type of multiple extents -- As you can probably see, i'm a bit confused with the whole thing. What should i do now? cheers, guStaVo

Ben Fennema wrote:

On Mon, Jul 22, 2002 at 11:28:35AM -0700, guStaVo ZaeRa wrote:

...

I've done as you suggested :

dd if=/dev/zero of=/dev/sr0 bs=2048 count=2295104

but since i don't have sr0 in my /dev dir, i assume it's supposed to be scd0.

[root@ksi4 /root]# dd if=/dev/zero of=/dev/scd0 bs=2048 count=2295104 dd: /dev/scd0: Read-only file system

So then i try to do this :

[root@ksi4 /root]# mkudffs --media-type=cdrw /dev/cdrom trying to change type of multiple extents

Wasn't that working before? I'm confused.. You've applied the kernel patch for DVD+RW, right?

Ben

believe me, i'm pretty confused as well.. yes, it was working before, but i tried to do several things, and now, i can't make it work again. so, i'm going to start from scratch. i've downloaded the 2.4.17 kernel source, and applied the corresponding UDF patch. Then, i compile the new kernel with 'make dep clean bzImage modules modules_install'. Then cp bzImage to /boot and run lilo. Then reboot. When i boot up with the new kernel, the UDF module is loaded, but when i try to do the dd command you suggested, i get the error i mentioned before. what i'm i forgetting? gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."

On Monday 22 July 2002 02:17 pm, Ben Fennema wrote:

On Mon, Jul 22, 2002 at 11:28:35AM -0700, guStaVo ZaeRa wrote:

...

I've done as you suggested :

dd if=/dev/zero of=/dev/sr0 bs=2048 count=2295104

but since i don't have sr0 in my /dev dir, i assume it's supposed to be scd0.

[root@ksi4 /root]# dd if=/dev/zero of=/dev/scd0 bs=2048 count=2295104 dd: /dev/scd0: Read-only file system

So then i try to do this :

[root@ksi4 /root]# mkudffs --media-type=cdrw /dev/cdrom trying to change type of multiple extents

Wasn't that working before? I'm confused.. You've applied the kernel patch for DVD+RW, right?

Ben

Ben, I think you are confusing Gustavo with me. We seem to be having the same problem.. 2 different threads but the same exact symptoms might have confused you. :P -- Wayde Milas Rarcoa (630) 654-2580

This is what I am doing:

cdrwtool -d /dev/sr0 -q pktsetup /dev/pktcdvd0 /dev/sr0 mount -t udf -o rw,noatime /dev/pktcdvd0 /cdrw cp -r linux /cdrw diff -ar --brief linux /cdrw/linux >> linux.diff

I try to do the same, and get the following errors. could someone tell me what i'm doing wrong? [root@ksi4 /dev]# cdrwtool -d /dev/cdrom -q using device /dev/cdrom 1280KB internal buffer setting write speed to 12x Settings for /dev/cdrom: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/cdrom. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank wait_cmd: Invalid argument Command failed: a1 01 00 00 00 00 00 00 00 00 00 00 - sense 05.30.02 blank disc: Invalid argument -- If I use Andy's dvd formatting tool (dvd+rw-format) 'dvd+rw-format -f /dev/cdrom' I get this: [root@ksi4 /root]# dvd+rw-format -f /dev/cdrom * DVD+RW format utility by , version 2.0. * 4.7GB DVD+RW media detected. * formatting 1.6\ one question: why does the formatting only go to 1.6%? -- if i try to use pktsetup, i get the following error: [root@ksi4 /root]# pktsetup /dev/pktcdvd0 /dev/scd0 ioctl: Inappropriate ioctl for device -- like i've stated before, i've been able to mount the drive as UDF, but unable to copy one large (~500MB) file to the drive. cheers, gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."

On Sun, Jul 28, 2002 at 03:39:36PM +0200, Peter Osterlund wrote:

On Fri, 19 Jul 2002, Peter Osterlund wrote:

...

On Fri, 19 Jul 2002, Ben Fennema wrote:

...

On Fri, Jul 19, 2002 at 01:33:13PM +0200, Peter Osterlund wrote:

...

On Thu, 18 Jul 2002, Ben Fennema wrote:

...

On Thu, Jul 18, 2002 at 11:31:21PM +0200, Peter Osterlund wrote:

...

I still think that's true, but I have some more information on the udf filesystem behavior. If I create a new udf filesystem and start adding lots of small files to it, at first (before dirty data writeback starts) the speed at which files are added is limited by how fast data can be *read* from the CD. I haven't looked at the udf code yet, but I would guess the udf filesystem reads a disk block for each file being added.

Hmm, it could be an issue with data being embedded in the inode. The data would go through the page cache, but the inode would go through the buffer cache, and this could force a read or something funky like that.

Ok, here's a patch which should fix the problem.

...

Let me know if it shows a noticeable improvement (or if you can't get it to apply nicely to whatever kernel version your using) =]

Yes it works perfectly. I applied it to the 2.4 cvs tree then copied it into the 2.4.19-rc2 tree.

I needed this patch for 2.5.29 too so I made a forward port. It appears to work fine and gives a big performance increase also in 2.5. Can you please have a look at the patch and maybe submit it to Linus if you think it's OK? Thanks.

I've actually been working on a "better" =] patch. The one I sent out was kind of a quick and dirty fix. I should be checking it into the UDF cvs tree soon =) Ben

On 21 Jul 2002, Manfred Kreisl wrote:

does anybody have Ben's patch for a 2.4.19-rc2 kernel. I have difficulties in applying Ben's patch to my kernel. I would like to test this patch, because i have the same problems (2k of 0s in files copied to cdrw and ultra low speed).

Here is the patch I use. This is exactly equivalent to applying Ben's patch the the 2.4 cvs tree, then copying the result into the kernel tree. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

Manfred Kreisl wrote:

Hello Peter,

Am Mon, 2002-07-22 um 02.40 schrieb Peter Osterlund:

...

On 21 Jul 2002, Manfred Kreisl wrote:

...

does anybody have Ben's patch for a 2.4.19-rc2 kernel. I have difficulties in applying Ben's patch to my kernel. I would like to test this patch, because i have the same problems (2k of 0s in files copied to cdrw and ultra low speed).

Here is the patch I use. This is exactly equivalent to applying Ben's patch the the 2.4 cvs tree, then copying the result into the kernel tree.

thanks for the patch.

I immediately patched my kernel without any problems and made some tests.

Here are the results:

- copying the kernel sources is quite a little bit faster than without Bens patch,

- the 2k errors are still there, but what I saw is: with a new initialized CD there are always 2k 0s at the beginning of the file, however with a used cd (data was already on this disk), 2k of garbage data is at the beginning of the file, never 0s. So it seems, that in case of an error the first block of a file is not written to disk.

- erasing the kernel tree on CD takes more time than writing (approx 20MByte in 10 minutes, 1 file per second). This is really terrible.

Manfred

are you doing this on CD-RW or DVD+RW? gustavo

On Thu, Jul 18, 2002 at 11:31:21PM +0200, Peter Osterlund wrote:

On Wed, 17 Jul 2002, Sergiy Kudryk wrote:

...

Is it possible to exclude mixed write/read operations with pktcdvd ?

For example when i move multiple small files from CDRW disk to harddrive mixed read /write transactions occurs. This degrades overall performance and potentially can destroy laser head of CDRW drive.

Can be in pktcdvd code implemented mechanism similar to semaphore: stop write transactions when we have read one and contra ?

This is what I wrote in an earlier mail:

I think the speed issue is caused by two things:

The udf filesystem seems to be inefficient at handling many small files. I don't know if that's caused by the current implementation or by something in the udf specification that requires such behavior.

The pktcdvd module is bypassing the the I/O elevator when creating write requests for the CDRW drive. This can make performance really suffer when there is a mixed read/write load. The 2.5 version of pktcdvd has fixed this problem, but a backport is not easy because it relies heavily on the new bio infrastructure in 2.5.

I still think that's true, but I have some more information on the udf filesystem behavior. If I create a new udf filesystem and start adding lots of small files to it, at first (before dirty data writeback starts) the speed at which files are added is limited by how fast data can be *read* from the CD. I haven't looked at the udf code yet, but I would guess the udf filesystem reads a disk block for each file being added.

yup, yup, yup. adding data to a file causes a read of the inode, even for new files.. bah, I guess I should fix that =] Ben