DVD+RW UFS: Overflooded Disk Cache?

rtg · 08-27-2005, 02:09 AM

Yesterday I've got a CD/DVD burner capable of writing DVD+RW and started testing it. The device is HLDTST (LG) GSA-4163B (2Mb cache, firmware version 104).
System: AthlonXP 1833Mhz/256Mb DDR333/KT400/

After acquiring cdrecord-proDVD and formatting the medium, i tried to burn some data on it prepared by mkisofs. It worked OK. Although cdrecord refused to blank the medium it was said that no blanking is needed.

My kernel version is 2.6.12.4 with UDF support enabled and I made the following steps described in the README for cdrecord-ProDVD:

created ufs on my /dev/dvd
mounted it rw
started copying the files to the DVD.

It worked flawlessly (albeit slow) until suddenly the process stopped and I saw these messages in the syslog:

Code:

kernel: hdc: media error (bad sector): status=0x51 { DriveReady SeekComplete Error }
kernel: hdc: media error (bad sector): error=0x34 { AbortedCommand LastFailedSense=0x03 }
kernel: ide: failed opcode was: unknown
kernel: end_request: I/O error, dev hdc, sector 568096

With the sector numbers incrementing constantly.
Then I interrupded the cp, waited until the drive stopped any activity (using LED blinking probe

) and tried to access the directory. The process hung up, and after a minute I've got

Code:

...
kernel: Unable to handle kernel paging request at virtual address 555502f7
kernel:  printing eip:
kernel: c01cc9d2
kernel: *pde = 00000000
kernel: Oops: 0000 [#1]
kernel: PREEMPT
kernel: Modules linked in: vmnet vmmon via_agp uhci_hcd ehci_hcd usbcore ntfs
kernel: CPU:    0
...

So kernel Oopsed.

After couple of minutes testing different conditions I found out that the UDF filesystem entries were broken and so the kernel could not handle such fs. Seems that the data could not be written to the medium at the speed the system expected it to and while the burning was still in progress, the system gave up waiting for the return code or something like that. Then it dropped some packets and continued happily. When I set up a delay of 10 seconds between the copy of each file (quick hack) the burn process ended successfully.

Finally here're the questions::
1. Why does cdrecord append a new session instead of overwriting the first track?
(corrected) 2. See http://www.linuxquestions.org/questi...hreadid=358753
for my another question about how to disable buffering on the block device.

New corrections: The problem does not depend on medium used. Now i have a Perl script which does unbuffered copying of the file (flushes the buffer every 2 Mb) and the process of writing lasts much shorter.

Matir · 09-01-2005, 02:14 PM

CDRecord appends a new session because the disk was not blanked.

Did you apply the required kernel patch for this to work?

rtg · 09-02-2005, 06:38 AM

Both GPL'd CDRecord and CDRecord-ProDVD refuse to blank the medium.

Regarding the kernel patch. Did you mean the one from http://fy.chalmers.se/~appro/linux/DVD+RW/ ?
If so, then it's useless for me as I have an IDE burner set up without scsi-emulation.
(I am not sure, but it seems that only the block devices can store filesystems and the mapping of raw device to my drive simply will not work)
With 2.6.x I can only burn disks w/ cdrecord while being root, but it is ok for my home PC.

Creating of the UDF FS on the DVD permits me using the drive as another hard disk, while being able to write to it under non-privileged user + the disk will be accessible under other OS.

Matir · 09-02-2005, 11:26 AM

As an obvious one, you are using RW media, right?

Also, the following statement from that page confuses me a bit, and makes it sound like 2.6 doesn't support the arbitrary filesystems:

Quote:

#

Linux 2.6 DVD+RW kernel support is planned in line with DVD+MRW kernel support. This [unfortunately] means that industry has to deliver a DVD+MRW capable unit first. Yes, the last sentence means that despite all the promises, there are no such units available on the market yet. As of the 1st of August 2003, Ricoh MP5240A, Philips DVDRW416K or BenQ DW400A do not actually implement Mt.Rainier/EasyWrite support. It remains to be seen if they will offer it in form of firmware upgrade. In either case, the [original] project goal is not only read-write support for DVD+[M]RW capable units themselves, but even playback of DVD+MRW formatted media in legacy DVD-ROM units (when defect list will be read and interpreted by OS software in opposite to Mt.Rainier firmware).

rtg · 09-02-2005, 11:38 AM

As I've got a kernel that supports UDF on CDRW / DVD+RW and even my old 3GB Harddrive now laying somewere

, I can say that it does support the arbitrary filesystems.
And it does not care on what medium. cdrom and ufs modules care - they make some special movements to 'finalize' the disk and so on. The other part of the kernel thinks that its completely normal.
I've writen some fast hack in Perl to copy files.

Code:

#!/usr/bin/perl

use strict;
use IO::File;

if (@ARGV<2) {
    print "Usage: $0 source1 [ source2 ... ] destination\n";
    exit;
}

my $bufsize=2*1024*1024; # 2Mb
my $dest = pop(@ARGV);
select(STDOUT);
$|=0;

foreach my $file (@ARGV) {
    if (! -f $file) {
        warn "Not a file: $file";
        next;
    }
    my $size = (stat($file))[7];
    my $fhin = IO::File->new();
    if(! $fhin->open("< $file")) {
        warn "Could not open $file for reading: $!";
        next;
    }

    my $fhout = IO::File->new();
    my ($vfn) = ( $file =~ m|(/?.+$)| );

    if (! $fhout->open(">$dest/$vfn")) {
        warn "Counld not open $dest/$vfn for writing: $!";
        next;
    }
    $fhout->autoflush(1);
    my $buffer;
    my $finished=0;
    my $rd=0;
    print "Copying $vfn ($size)\n";
    while ($rd = $fhin->read($buffer, $bufsize)) {
        $finished += $rd;
        $fhout->sync;
        printf("$vfn:\t%8d\n", $finished);
        $fhout->print($buffer);
    }
    print "\n";
    $fhin->close();
    $fhout->close();
}

It's a hack but it does its job. The main point is that it tries to flush buffers after each 2 Mb. I think in can be done in some more elegant way... If nothing helps I will go and try to fix the kernel module

.

rtg · 04-07-2006, 03:14 PM

After several months the solution has been found. The packet writing subsystem under linux kernel controls the writing speed, buffer size and other issues.