Peter Osterlund
On Sat, 9 Mar 2002, Paul wrote:
Now, I get these guys, but just every second or so, when writing.
Mar 9 23:04:38 squish kernel: scsi : aborting command due to timeout : pid 3160, scsi0, channel 0, id 0, lun 0 0x35 00 00 00 00 00 00 00 00 00
It looks like the flush cache command needs more than 5 seconds to finish. Does this patch help?
--- linux/drivers/block/pktcdvd.c.old Sun Mar 10 17:22:01 2002 +++ linux/drivers/block/pktcdvd.c Sun Mar 10 17:21:36 2002 @@ -1633,6 +1633,7 @@ init_cdrom_command(&cgc, NULL, 0, CGC_DATA_NONE); cgc.cmd[0] = GPCMD_FLUSH_CACHE; cgc.quiet = 1; + cgc.timeout = 20*HZ;
/* * the IMMED bit -- we default to not setting it, although that
Hi; Yes, this patch silences the timeout complaints.
Writing seems very slow, but Im not sure how fast it should be. rm -rf on ~600 files comprising 89M took 30 minutes. (and generates a load of 3).
I have noticed before that rm -rf on a udf filesystem is quite slow, but I don't remember if it used to be that slow.
Is it slower than the 2.4.18-pre4 version? I didn't think the extra flush cache commands would slow things down, because the drive will have to finish the write commands anyway before it can start reading. But that's just the theory, in practice, anything can happen ;-)
If anything 2.4.18-pre4 was slower. I did a time (tar cpSf - /usr/local/bin | tar xpSvf -) under 2.4.19-pre, and for 904 files/ 156M it took 27minutes to complete, and a sync didnt finish for 20 minutes after that. I tried a similar test on 2.4.18-pre, but it locked my machine hard. The tar didnt complete, and it took at least 30 minutes to write 148M.
The process of writing seems very consistant; the drive is pretty quiet, with some seeking sounds, and the 'writing' light on for a 2-3 seconds, then the light goes out, and the drive makes a brief 'spin up' sound for a second, repeat.
I also think we could handle the read/write speeds smarter in the driver. If you are mixing reads and writes to the drive, it is probably faster to use the same read and write speed. The read speed should only be increased if there are many reads and no writes.
Nothing in userspace was reading from the drive, but it seemed to be spending about 1/4 of the time reading-- if that point when the 'writing' light goes out, and it makes the spin up noise is reading. In a previous thread it was mentioned that writing an incomplete packet would require the kernel to read the missing part of the packet, so it could write back a whole packet. Is this something that should be happening this frequently? (it seems hard on the drive) This is an ide cdrw, accessed via scsi emulation. Paul set@pobox.com
-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com