I've been able to write files in the range of 1 kB - 2 GB on an HP dvd200i drive in UDF. i'm about to do the same test on an 100i drive. gustavo
Ben Fennema wrote:
On Mon, Aug 05, 2002 at 12:01:19PM -0700, guStaVo ZaeRa wrote:
I've been able to write files in the range of 1 kB - 2 GB on an HP dvd200i drive in UDF.
i'm about to do the same test on an 100i drive.
So whatcha change?
I inserted Andy's code (look in the UDF DVD+RW thread) as specified. :] gustavo
guStaVo ZaeRa wrote:
I've been able to write files in the range of 1 kB - 2 GB on an HP dvd200i drive in UDF.
i'm about to do the same test on an 100i drive.
same test completed successfully on the HP dvd 100i on the first try. The second run (after re-formatting the disk), ended in hanging the drive -repetitive sounds were generated from the drive (you know, the kind that show that the drive is not able to read the disk). also, i got this : sr0: CDROM (ioctl) error, command: Synchronize Cache 00 00 00 00 00 00 00 00 00 Info fld=0x230430, Current sr00:00: sense key Medium Error i am about to switch back to the 200i drive to see if this problem is specifc to the 100i drive, or whether i have a bad media. Andy Polyakov wrote:
i did a rm -Rf * on the mounted dvd+rw <-- took almost 30mins...
wow! well, i have no other comment... it must be udf issue... btw, i discussed optimal udf options with ben, he recommended 'mkudffs --spartable=2 --media-type=cdrw' for dvd+rw. i'll post it on my page next weekend.
ok, now it's much better. now it only took one second! :]
then, i did a cp -R /usr/src/linux ~/2gigfile /mnt/dvd+rw which ended succesfully, but i had this in my dmesg: ... scsi : aborting command due to timeout : pid 50348, scsi0, channel 0, id 0, lun 0 Synchronize Cache 00 00 00 00 00 00 00 00 00
SRpnt->sr_timeout_per_command needs to be increased then! Right now it's 5*HZ, set it to say 30*HZ.
ok, done. the timeouts were generated when i wrote files > 1GB. The messages have disappeared now, but it seems to write a bit slowly... copying a 2GB file took over 30 mins... is it writing at 2.4x ? i can see that in get_capabilities() in sr.c, the speed is set to 1 if the capabilites were not read from the drive. Otherwise the speed is set to : scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176; in my case that is 32/32, but the writer cannot write at 32! is there any way i can find out where to look for the write speed? another (kinda silly) question: how do #define the kernel modules to DEBUG, so i can get more info? gustavo
I've been able to write files in the range of 1 kB - 2 GB on an HP dvd200i drive in UDF.
same test completed successfully on the HP dvd 100i on the first try. The second run (after re-formatting the disk), ended in hanging the drive -repetitive sounds were generated from the drive (you know, the kind that show that the drive is not able to read the disk).
also, i got this : sr0: CDROM (ioctl) error, command: Synchronize Cache 00 00 00 00 00 00 00 00 00 Info fld=0x230430, Current sr00:00: sense key Medium Error
Well, if media turned rotten there is not much one can do for now, right? BTW, what do you mean by "re-formatting"? 'dvd+rw-format -f ...' or 'mkudffs ...' alone? It was observed [by several people now] that excessive reformats, i.e. with 'dvd+rw-format -f ...' *or* equivalent windows programs, render DVD+RW media unusable already after 10-20-30 reformats. So that you should run dvd+rw-format only once and then stick to mkudffs (or growisofs for that matter:-).
but it seems to write a bit slowly... copying a 2GB file took over 30 mins... is it writing at 2.4x ?
You have to understand that all filesystem I/O passes common buffer cache and working with large filesets might put quite a pressure on VM subsystem which might start suffering from excessive page scans. Under such conditions delays can be more than just "noticeable." Another user has reported about 4 times better growisofs performance after he bound his /dev/scdN to /dev/raw/rawM device and bypassed the buffer cache. Of course in this case /dev/raw/rawM is not an option and you might have to learn to accept and live with apparently suboptimal writing rates:-)
i can see that in get_capabilities() in sr.c, the speed is set to 1 if the capabilites were not read from the drive. Otherwise the speed is set to :
scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
in my case that is 32/32, but the writer cannot write at 32! is there any way i can find out where to look for the write speed?
As far as I undertand you can't control DVD writing speed. The speed settings you mention are applicable only when CD media is mounted. Well, Ricoh might have implementd DVD speed vendor-specific control, but I wouldn't know, never seen any vendor documentation:-( But as it is the unit always writes as fast as it can. What you experience is rather VM performance problem than unit's "fault." Well, write request segmentation might affect unit's performance. What I mean is that when you say "write 2KB," the unit has to read 32KB, replace corresponding 2KB and then write out resulting 32KB. Now when you copy large file write requests are of course larger than 2KB, but they are not necessarily aligned at 32KB, therefore requests effectively get fragmented anyway. Some caching algorithm is of course in place, but obviously it's not 100% effective as the unit does ask for "SYNCHRONIZE CACHE" now and then. A.
Andy Polyakov wrote:
Well, if media turned rotten there is not much one can do for now, right? BTW, what do you mean by "re-formatting"? 'dvd+rw-format -f ...' or 'mkudffs ...' alone? It was observed [by several people now] that excessive reformats, i.e. with 'dvd+rw-format -f ...' *or* equivalent windows programs, render DVD+RW media unusable already after 10-20-30 reformats. So that you should run dvd+rw-format only once and then stick to mkudffs (or growisofs for that matter:-).
no, i'm only using mudffs. :) i put the dvd 200i drive back in, and had no problems copying a 2GB file onto it. Not even one error message! :D
You have to understand that all filesystem I/O passes common buffer cache and working with large filesets might put quite a pressure on VM subsystem which might start suffering from excessive page scans. Under such conditions delays can be more than just "noticeable." Another user has reported about 4 times better growisofs performance after he bound his /dev/scdN to /dev/raw/rawM device and bypassed the buffer cache. Of course in this case /dev/raw/rawM is not an option and you might have to learn to accept and live with apparently suboptimal writing rates:-)
ok... i can live with that, but would there be a way of speeding up the VM? :)
i can see that in get_capabilities() in sr.c, the speed is set to 1 if the capabilites were not read from the drive. Otherwise the speed is set to :
scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
in my case that is 32/32, but the writer cannot write at 32! is there any way i can find out where to look for the write speed?
As far as I undertand you can't control DVD writing speed. The speed settings you mention are applicable only when CD media is mounted. Well, Ricoh might have implementd DVD speed vendor-specific control, but I wouldn't know, never seen any vendor documentation:-( But as it is the unit always writes as fast as it can. What you experience is rather VM performance problem than unit's "fault." Well, write request segmentation might affect unit's performance. What I mean is that when you say "write 2KB," the unit has to read 32KB, replace corresponding 2KB and then write out resulting 32KB. Now when you copy large file write requests are of course larger than 2KB, but they are not necessarily aligned at 32KB, therefore requests effectively get fragmented anyway. Some caching algorithm is of course in place, but obviously it's not 100% effective as the unit does ask for "SYNCHRONIZE CACHE" now and then.
ah! ok, that clears up many things! thanks a lot, andy! :] gustavo
On Mon, Aug 05, 2002 at 03:38:34PM -0700, guStaVo ZaeRa wrote:
There are serious issues writing to slow devices. Their slow =)
Ben
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =) Ben
Ben Fennema wrote:
On Mon, Aug 05, 2002 at 03:38:34PM -0700, guStaVo ZaeRa wrote:
There are serious issues writing to slow devices. Their slow =)
Ben
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =)
I don't think that that was the case, though... The HD was barely running, and the CPU load was extremely low. If there had been thrashing, the HD would have been freaking out, like you said, and would eventually lock up the (I/O) system. gustavo
There are serious issues writing to slow devices. Their slow =)
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =)
I don't think that that was the case, though...
Do you have more than 2GB RAM installed? Provided that we're talking about 2GB large filesets...
The HD was barely running, and the CPU load was extremely low. If there had been thrashing, the HD would have been freaking out,
No it wouldn't. Buffer cache is not subject to swapping so that HD would remain idle. Buffers fill up memory, page scanner kicks in, but there's not much it can do, it's all dirty blocks to be written out and you can only wait till it actually takes place. A.
On Tue, Aug 06, 2002 at 01:14:16AM +0200, Andy Polyakov wrote:
Do you have more than 2GB RAM installed? Provided that we're talking about 2GB large filesets...
The HD was barely running, and the CPU load was extremely low. If there had been thrashing, the HD would have been freaking out,
No it wouldn't. Buffer cache is not subject to swapping so that HD would remain idle. Buffers fill up memory, page scanner kicks in, but there's not much it can do, it's all dirty blocks to be written out and you can only wait till it actually takes place.
Right, right, right.. So what happens is all other I/O gets stuck waiting for all the buffers your writing to the DVD+RW to get written and you have to site around twidling your thumbs =) Ben
On Monday 05 August 2002 05:46 pm, Ben Fennema wrote:
On Mon, Aug 05, 2002 at 03:38:34PM -0700, guStaVo ZaeRa wrote:
There are serious issues writing to slow devices. Their slow =)
Ben
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =)
Ben
Ok, maybe I shouldnt ask this seeing as that im going out of town tomorrow, but, starting from a fresh kernel, what exactly is the process to try my hand at dvd writting again? :P Wayde
There are serious issues writing to slow devices. Their slow =)
Ben
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =)
Ben
Ok, maybe I shouldnt ask this seeing as that im going out of town tomorrow, but, starting from a fresh kernel, what exactly is the process to try my hand at dvd writting again? :P
Just to avoid possible confusion. We're talking about DVD+RW which is different from DVD-RW. As for "what to do exactly." Just take your vacation and check http://fy.chalmers.se/~appro/linux/DVD+RW/ when you get back. I plan to update the page and post the new kernel patch upcoming weekend. Cheers. A.
On Monday 05 August 2002 06:20 pm, Andy Polyakov wrote:
There are serious issues writing to slow devices. Their slow =)
Ben
ok... i'll just live with it, then. :)
What seems to happen is your entire memory is filled with buffers waiting to be written to the disc, and so you start thrashing at which point everything goes to hell =)
Ben
Ok, maybe I shouldnt ask this seeing as that im going out of town tomorrow, but, starting from a fresh kernel, what exactly is the process to try my hand at dvd writting again? :P
Just to avoid possible confusion. We're talking about DVD+RW which is different from DVD-RW. As for "what to do exactly." Just take your vacation and check http://fy.chalmers.se/~appro/linux/DVD+RW/ when you get back. I plan to update the page and post the new kernel patch upcoming weekend.
Cheers. A.
ok, im talking about DVD +RW too.. I'll try this weekend. Oh, and i wish it was a vacation :P -- Wayde Milas Rarcoa (630) 654-2580
guStaVo ZaeRa wrote:
guStaVo ZaeRa wrote:
I've been able to write files in the range of 1 kB - 2 GB on an HP dvd200i drive in UDF.
i'm about to do the same test on an 100i drive.
same test completed successfully on the HP dvd 100i on the first try. The second run (after re-formatting the disk), ended in hanging the drive -repetitive sounds were generated from the drive (you know, the kind that show that the drive is not able to read the disk).
also, i got this : sr0: CDROM (ioctl) error, command: Synchronize Cache 00 00 00 00 00 00 00 00 00 Info fld=0x230430, Current sr00:00: sense key Medium Error
i am about to switch back to the 200i drive to see if this problem is specifc to the 100i drive, or whether i have a bad media.
on the 100i drive, writing a 2GB file ended in an error message (after writing ~600MB) specifying that there were no space left on the device. The drive kept on trying to access the media, and generated a million messages like this one in the kernel ring: scsi0: ERROR on channel 0, id 0, lun 0, CDB: Request Sense 00 00 00 40 00 Info fld=0x47130, Current sd0b:00: sense key Medium Error I/O error: dev 0b:00, sector 1178840 on the 200i drive things seem to work fine. The "scsi : aborting command due to timeout : pid 50348, scsi0, channel 0, id 0, lun 0 Synchronize Cache 00 00 00 00 00 00 00 00 00" messages seem to have disappeared for good. :] gustavo
participants (4)
-
Andy Polyakov
-
Ben Fennema
-
guStaVo ZaeRa
-
Wayde Milas