Hi! I have uploaded a new version of the packet writing driver here: http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.19-pre2.patch.b... This patch was generated from kernel 2.4.19-pre2, but should work also with kernel 2.4.18. (and probably 2.4.17 too.) The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages: 1. The hack in scsi_lib.c to retry failed read commands caused by the device not being ready is no longer needed. 2. Some drives report "command sequence error" if you try to send them a read command before the previous write command is finished. Those drives didn't work before, but I hope they do work with the new version. 3. IDE drives that previously only worked with ide-scsi emulation may now work also in native ide mode. I would like to receive feedback on this version, since I don't have the hardware necessary to provoke the problems mentioned in 2 and 3. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Sun, 2002-03-03 at 12:45, Peter Osterlund wrote:
Hi!
I have uploaded a new version of the packet writing driver here:
http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.19-pre2.patch.b...
This patch was generated from kernel 2.4.19-pre2, but should work also with kernel 2.4.18. (and probably 2.4.17 too.)
Works great for me (HP N5425 Laptop, UJDA710 ATAPI CD-RW/DVD-ROM, Linux 2.4.18)! First time, too. Previous patches resulted in instant "I/O error" upon any attempt to write to the CDRW. Thanks!!
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
1. The hack in scsi_lib.c to retry failed read commands caused by the device not being ready is no longer needed.
I have a desktop w/a Yamaha CRW-6416SXZ (Advansys PCI SCSI adapter). Should I no longer see the "Device 0b:01 not ready: cmd=0, sector=9868, nr_sectors=4"? I haven't had a chance to test my desktop, just the laptop.
3. IDE drives that previously only worked with ide-scsi emulation may now work also in native ide mode.
Mine works w/ide-scsi and ide native. Before, neither worked. I use ide-scsi for compatibility w/cdrecord and cdrdao.
I would like to receive feedback on this version, since I don't have the hardware necessary to provoke the problems mentioned in 2 and 3.
Now I have only one problem - when I have a UDF filesystem mounted RW though /dev/pktcdrw, the drive will not spin down. "mount -t udf -o ro /dev/sr0 /mnt/cdrw" still spins down, but "mount -t udf -o rw,noatime /dev/pktcdrw /mnt/cdrw" will not. Shortly after "umount /mnt/cdrw", the drive will spin down. Any ideas? -Cory
On 4 Mar 2002, Cory Bell wrote:
Works great for me (HP N5425 Laptop, UJDA710 ATAPI CD-RW/DVD-ROM, Linux 2.4.18)! First time, too. Previous patches resulted in instant "I/O error" upon any attempt to write to the CDRW. Thanks!!
I'm glad to hear that.
1. The hack in scsi_lib.c to retry failed read commands caused by the device not being ready is no longer needed.
I have a desktop w/a Yamaha CRW-6416SXZ (Advansys PCI SCSI adapter). Should I no longer see the "Device 0b:01 not ready: cmd=0, sector=9868, nr_sectors=4"? I haven't had a chance to test my desktop, just the laptop.
No, you should no longer see that message.
3. IDE drives that previously only worked with ide-scsi emulation may now work also in native ide mode.
Mine works w/ide-scsi and ide native. Before, neither worked. I use ide-scsi for compatibility w/cdrecord and cdrdao.
OK, thanks for the data point.
Now I have only one problem - when I have a UDF filesystem mounted RW though /dev/pktcdrw, the drive will not spin down. "mount -t udf -o ro /dev/sr0 /mnt/cdrw" still spins down, but "mount -t udf -o rw,noatime /dev/pktcdrw /mnt/cdrw" will not. Shortly after "umount /mnt/cdrw", the drive will spin down. Any ideas?
I don't know. I haven't seen this with my drives. (An Acer 4406EU and a Freecom Traveller.) -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Sun, Mar 03 2002, Peter Osterlund wrote:
Hi!
I have uploaded a new version of the packet writing driver here:
http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.19-pre2.patch.b...
This patch was generated from kernel 2.4.19-pre2, but should work also with kernel 2.4.18. (and probably 2.4.17 too.)
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
That's a good idea, I definitely agree with that. Some comments on the implementation -- I'd much rather see this done at the lower level, so ide-cd or sr would sync cache on the first read on its own. The implementation might be a bit nastier though, as you would have to handle that async and not blocking like you do now. BTW, what is the cache_sync_mutex good for?! AFAICS, we don't need to serialize this from the pktcdvd view point, and the cd drivers will serialize special commands on its own. unflushed_writes does need a barrier at least, but I'd rather see that be a bit flag instead. A block mutex for a simple variable is quite costly and risks schedule storms. -- Jens Axboe
On Mon, 4 Mar 2002, Jens Axboe wrote:
On Sun, Mar 03 2002, Peter Osterlund wrote:
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
That's a good idea, I definitely agree with that. Some comments on the implementation -- I'd much rather see this done at the lower level, so ide-cd or sr would sync cache on the first read on its own.
I didn't know if this behaviour is always wanted, since there are so many different modes for CDs, and I don't know enough about them all. If it is always wanted, I agree it would be better to put this functionality at a lower level.
The implementation might be a bit nastier though, as you would have to handle that async and not blocking like you do now.
For the 2.5 version of the packet driver, doing the syncs at a lower level may actually simplify things. The 2.5 version is not limited to handling of a single packet at a time. A state machine is used for driving each packet and the packet driver can submit multiple reads and writes asynchronously to the underlying cdrom device queue, which is then responsible for sorting and merging the requests. In this scenario it would be quite hard for the packet driver to insert cache sync commands at the right spots in the request queue without limiting the amount of request reordering the underlying CD queue can do. The 2.5 version is actually already working, except for two things: 1. It doesn't have the "cache sync before read" logic implemented. 2. Since everything is now done with "bio" objects, the functionality to fill in missing parts of packets with data from the buffer cache doesn't work. The latest 2.5 version is available here: http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.5.patch.bz2 -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Mon, Mar 04 2002, Peter Osterlund wrote:
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
That's a good idea, I definitely agree with that. Some comments on the implementation -- I'd much rather see this done at the lower level, so ide-cd or sr would sync cache on the first read on its own.
I didn't know if this behaviour is always wanted, since there are so many different modes for CDs, and I don't know enough about them all. If it is always wanted, I agree it would be better to put this functionality at a lower level.
If we are seeing this problem on cd-rw writing, then I bet the problems will be pretty much identical for any type of 'write lots of stuff, now start read' type of access.
The implementation might be a bit nastier though, as you would have to handle that async and not blocking like you do now.
For the 2.5 version of the packet driver, doing the syncs at a lower level may actually simplify things. The 2.5 version is not limited to handling of a single packet at a time. A state machine is used for driving each packet and the packet driver can submit multiple reads and writes asynchronously to the underlying cdrom device queue, which is then responsible for sorting and merging the requests. In this scenario it
Good
would be quite hard for the packet driver to insert cache sync commands at the right spots in the request queue without limiting the amount of request reordering the underlying CD queue can do.
Indeed, that this point it's pretty much a requirement that the lower level does it. Although in 2.5 you could do cool stuff like actually prefill a cache flush cdb inside the request and add it directly to the target queue.
2. Since everything is now done with "bio" objects, the functionality to fill in missing parts of packets with data from the buffer cache doesn't work.
Since basically everything is in the page cache these days, you might as well just ignore the buffer cache completely and just to page cache lookups. What I had in mind was something like: - on write to packet device, allocate a bio big enough to hold the entire packet. - have packet elevator just fill in the bio_vecs on merged writes - fill in bio_vecs with pages from the page cache You will probably need a bit of logic to clean the buffers on the page on end I/O (maybe even pre-clean them so a different writer won't be stuck on locking the buffer for writeout, only to wakeup when the buffer has been cleaned elsewhere). I can try something like this in the 2.5 tree when I get back from Norway. I plan on getting the 2.5 stuff in shape (seems it's already pretty good, excellent work Peter!) and getting it in the kernel very soon now. Peter, I hope you don't mind, but I do consider you the 2.4 maintainer of the patch these days. You have been the defacto maintainer for quite some time anyways. -- Jens Axboe
On Tue, 5 Mar 2002, Jens Axboe wrote:
I plan on getting the 2.5 stuff in shape (seems it's already pretty good, excellent work Peter!)
Thanks, but I do suspect there is code in the patch that tries to handle cases that can never happen. I didn't know exactly what values of bv_len and bv_offset are valid in the bio_vec struct, so the packet driver tries to handle all theoretically possible cases. If in reality these values always satisfy some alignment/size restriction, the code can probably be simplified.
and getting it in the kernel very soon now.
Cool.
Peter, I hope you don't mind, but I do consider you the 2.4 maintainer of the patch these days. You have been the defacto maintainer for quite some time anyways.
No, I don't mind at all. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Mon, 4 Mar 2002, Jens Axboe wrote:
On Sun, Mar 03 2002, Peter Osterlund wrote:
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
... BTW, what is the cache_sync_mutex good for?! AFAICS, we don't need to serialize this from the pktcdvd view point, and the cd drivers will serialize special commands on its own. unflushed_writes does need a barrier at least, but I'd rather see that be a bit flag instead. A block mutex for a simple variable is quite costly and risks schedule storms.
Without the mutex the cache sync command didn't always end up between the write and the read. I think this scenario can happen: 1. pkt_make_request is called with a read request. 2. unflushed_writes is 0, so no cache sync is generated. 3. pkt_make_request remaps the read and __make_request in ll_rw_blk.c is called. This function calls __get_request_wait which sleeps. 4. The kcdrwd thread is woken up and injects a new write request. 5. __make_request continues and inserts the read request immediately following the write request. Besides, in an SMP environment, couldn't pkt_make_request execute at the same time as the kcdrwd thread? Maybe I misunderstood what was really happening, but I do know that without the mutex, the sync command wasn't always inserted at the right place in the request queue. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Mon, Mar 04 2002, Peter Osterlund wrote:
BTW, what is the cache_sync_mutex good for?! AFAICS, we don't need to serialize this from the pktcdvd view point, and the cd drivers will serialize special commands on its own. unflushed_writes does need a barrier at least, but I'd rather see that be a bit flag instead. A block mutex for a simple variable is quite costly and risks schedule storms.
Without the mutex the cache sync command didn't always end up between the write and the read. I think this scenario can happen:
1. pkt_make_request is called with a read request. 2. unflushed_writes is 0, so no cache sync is generated. 3. pkt_make_request remaps the read and __make_request in ll_rw_blk.c is called. This function calls __get_request_wait which sleeps. 4. The kcdrwd thread is woken up and injects a new write request. 5. __make_request continues and inserts the read request immediately following the write request.
Besides, in an SMP environment, couldn't pkt_make_request execute at the same time as the kcdrwd thread?
Maybe I misunderstood what was really happening, but I do know that without the mutex, the sync command wasn't always inserted at the right place in the request queue.
I would consider this bandaid... Yet another reason for making the lower levels issue the actual flush, then there is no need for you to synchronize the flush from the pktcdvd level. -- Jens Axboe
Hello
--- Peter Osterlund
Hi!
I have uploaded a new version of the packet writing driver here:
http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.19-pre2.patch.b...
This patch was generated from kernel 2.4.19-pre2, but should work also with kernel 2.4.18. (and probably 2.4.17 too.)
...
Thank you Peter for good work. Now i can succesfully write (kernel 2.4.18) with IDE Mitsumi CDRW 4805 to UDF CDRW disc without errors. First my attempt was patch (2.4.19-pre2) applying to kernel 2.4.17; i compile and install new modules, but after reboot i get from kernel errors about unresolved symbols in pktcdvd.o, sr.o, sr_mod.o modules (perhaps because i have used "old" kernel 2.4.17 patched with packet-2.4.18-pre4-2 (too lazy to compile new kernel image :-) )). Second attempt was with kernel 2.4.18 - i build new patched (2.4.19-pre2) kernel and modules .. and get success with UDF write to CDRW disc (no warnings and errors (for this time)). Thanks again ! Regards, Sergiy Kudryk. __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
On Thu, 7 Mar 2002, Sergiy Kudryk wrote:
Thank you Peter for good work.
Now i can succesfully write (kernel 2.4.18) with IDE Mitsumi CDRW 4805 to UDF CDRW disc without errors.
And thank you for all your help with testing, which made it possible for me to figure out what the problem was. Without your help, I don't think the problem would have been fixed yet. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hello, First, thanks for the new patch. Now I can use my cd-writer without the annoying error messages saying that the drive is not ready. I have a question too. How can I setup permissions to allow my regular users to write to the cd-rw? Everytime a regular user mount the pktcdvd0 device it changes the ownership and group of my mount point to root :-( This is the oposite of what happens when I mount a floppy (the ownership and group become the regular user). Thanks again and keep on the good work, Paulo
On Thu, Mar 07, 2002 at 04:37:08PM -0300, Paulo Jose da Silva e Silva wrote:
I have a question too. How can I setup permissions to allow my regular users to write to the cd-rw? Everytime a regular user mount the pktcdvd0 device it changes the ownership and group of my mount point to root :-( This is the oposite of what happens when I mount a floppy (the ownership and group become the regular user).
My guess is, / on the cd-rw is owned by root. When you mount a filesystem the permissions of the mountpoint are changed to the permissions of the root directory of the filesystem. Ben
On Thu, 2002-03-07 at 11:52, Ben Fennema wrote:
My guess is, / on the cd-rw is owned by root. When you mount a filesystem the permissions of the mountpoint are changed to the permissions of the root directory of the filesystem.
I see the same thing - the first thing I do after mounting a newly formatted cdrw is "chmod a+w /mnt/cdrw". Any chance you might change mkudffs and possibly cdrwtool to allow specifying the root dir permissions and ownership? I know "secure by default" is good thing, but I see udf/cdrw used mainly as a mega-floppy, not a secure medium. I can also see this becoming an FAQ, considering most users are not root (one would hope anyway). -Cory
You can use the sudo command to give certain users the ability to mount and umount devices, also for other things. Check out: http://www.courtesan.com/sudo/sudo.html Should have everything you need to set it up. Good Luck. Todd Paulo Jose da Silva e Silva wrote:
Hello,
First, thanks for the new patch. Now I can use my cd-writer without the annoying error messages saying that the drive is not ready.
I have a question too. How can I setup permissions to allow my regular users to write to the cd-rw? Everytime a regular user mount the pktcdvd0 device it changes the ownership and group of my mount point to root :-( This is the oposite of what happens when I mount a floppy (the ownership and group become the regular user).
Thanks again and keep on the good work,
Paulo
-- Todd Tolliver Dept. of ECE; UMass, Amherst Amherst, MA 01003 ph: 413-545-4615 (413-545-3661) fx: 413-545-4611
On Thu 07 Mar 2002 16:37, Paulo Jose da Silva e Silva wrote:
I have a question too. How can I setup permissions to allow my regular users to write to the cd-rw?
Did you try to use the gid, uid and umask options for udf? If not, try to mount the device using: # mount -t udf -o rw,noatime,gid=cdrw,umask=002 That should (theorically) make the files be owned by the 'cdrw' group and allow them to write... Optionally you can use the uid to make the files owned by any user... -- Raphael Derosso Pereira - DephiNit *-=-*-=--=-*-=-*-=--=*=-* / dephinit@softhome.net / *-=-*-=--=-*-=-*-=--=*=-* -=*=--=*=--=*=--=*=--=*=--=*=--=*=- | Debian GNU/Linux Addicted User | | Use it, Abuse it. It's Free!!! | -=*=--=*=--=*=--=*=--=*=--=*=--=*=-
On Thu 07 Mar 2002 16:37, Paulo Jose da Silva e Silva wrote:
I have a question too. How can I setup permissions to allow my regular users to write to the cd-rw?
Did you try to use the gid, uid and umask options for udf?
If not, try to mount the device using:
# mount -t udf -o rw,noatime,gid=cdrw,umask=002
That should (theorically) make the files be owned by the 'cdrw' group and allow them to write... Optionally you can use the uid to make the files owned by any user...
Check out the "user" option for mount. Unless I'm mistaken then anyone can mount it, they have ownership of it, and only the mounter can unmount it.
-- Raphael Derosso Pereira - DephiNit
Jeff Voskamp - Information Systems & Technology, University of Waterloo
On Fri, 2002-03-08 at 12:05, Jeff Voskamp wrote:
Check out the "user" option for mount. Unless I'm mistaken then anyone can mount it, they have ownership of it, and only the mounter can unmount it.
I believe you're mistaken. From the mount manpage: user - Allow an ordinary user to mount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid). When mounted, the permissions on the filesystem itself will still take effect. I believe when you mount a filesystem with no permission info (i.e. iso9660, vfat) the user or owner option treats the user who mounted the filesystem as the owner of all files. -Cory
Em Sex, 2002-03-08 às 15:39, Raphael Derosso Pereira - DephiNit
If not, try to mount the device using:
# mount -t udf -o rw,noatime,gid=cdrw,umask=002
That should (theorically) make the files be owned by the 'cdrw' group and allow them to write... Optionally you can use the uid to make the files owned by any user...
I have tried the gid and umask options and I still couldn't write to cdrw. Hence, I have the felling that these options do not work as you expect them to do. As I said before, changing the permissions of the mounted cd-rw made the trick for me. Thank you all for the replies! Paulo
Peter Osterlund
Hi!
I have uploaded a new version of the packet writing driver here:
<...>
I would like to receive feedback on this version, since I don't have the hardware necessary to provoke the problems mentioned in 2 and 3.
-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hi; I tried this latest patch against 2.4.18. So, here is some feedback; if any more info is wanted, just ask. Thanks for the work... Previously, using packet-2.4.18-pre4.patch, it worked, but I would get loads of these messages: Feb 20 21:29:27 squish kernel: Device 0b:00 not ready: cmd=0, sector=10124, nr_sectors=116 Feb 20 21:29:33 squish last message repeated 83 times Feb 20 21:29:33 squish kernel: Device 0b:00 not ready: cmd=0, sector=360832, nr_sectors=80 Feb 20 21:29:34 squish last message repeated 16 times Feb 20 21:29:35 squish kernel: Device 0b:00 not ready: cmd=0, sector=1416, nr_sectors=120 Feb 20 21:29:36 squish last message repeated 16 times Feb 20 21:30:15 squish kernel: Device 0b:00 not ready: cmd=0, sector=369024, nr_sectors=12 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 Mar 9 23:04:56 squish kernel: scsi : aborting command due to timeout : pid 3180, scsi0, channel 0, id 0, lun 0 0x35 00 00 00 00 00 00 00 00 00 Mar 9 23:05:07 squish kernel: scsi : aborting command due to timeout : pid 3193, scsi0, channel 0, id 0, lun 0 0x35 00 00 00 00 00 00 00 00 00 Mar 9 23:05:15 squish kernel: scsi : aborting command due to timeout : pid 3201, scsi0, channel 0, id 0, lun 0 0x35 00 00 00 00 00 00 00 00 00 Mar 9 23:05:24 squish kernel: scsi : aborting command due to timeout : pid 3209, scsi0, channel 0, id 0, lun 0 0x35 00 00 00 00 00 00 00 00 00 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). The driver determines the read/write speed of the drive as 12/8, though the drive is only supposed to be able to do speed 4 on cdrw media. (32/8/4) 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. Paul set@pobox.com This is the the drivers initial message: Mar 9 22:24:12 squish kernel: pktcdvd: writer sr0 sucessfully registered Mar 9 22:24:29 squish kernel: pktcdvd: speed (R/W) 12/8 Mar 9 22:24:34 squish kernel: pktcdvd: inserted media is CD-RW Mar 9 22:24:35 squish kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Mar 9 22:24:35 squish kernel: pktcdvd: speed (R/W) 12/8 Mar 9 22:24:35 squish kernel: pktcdvd: 547648kB available on disc Mar 9 22:24:35 squish kernel: UDF-fs DEBUG lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 Mar 9 22:24:35 squish kernel: UDF-fs DEBUG super.c:1413:udf_read_super: Multi-session=0 Mar 9 22:24:35 squish kernel: UDF-fs DEBUG super.c:410:udf_vrs: Starting at sector 16 (2048 byte sectors) Mar 9 22:24:39 squish kernel: UDF-fs DEBUG super.c:753:udf_load_pvoldesc: recording time 1015630529/774562, 2002/03/08 18:35 (1ed4) Mar 9 22:24:39 squish kernel: UDF-fs DEBUG super.c:954:udf_load_logicalvol: Partition (0:0) type 2 on volume 1 Mar 9 22:24:39 squish kernel: UDF-fs DEBUG super.c:964:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=32, partition=0 Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:800:udf_load_partdesc: Searching map: (0 == 0) Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:833:udf_load_partdesc: unallocatedSpaceBitmap (part 0) @ 0 Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:874:udf_load_partdesc: Partition (0:0 type 1522) starts at physical 2464, block length 271072 Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:1207:udf_load_partition: Using anchor in block 256 Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:1440:udf_read_super: Lastblock=0 Mar 9 22:24:40 squish kernel: UDF-fs DEBUG super.c:725:udf_find_fileset: Fileset at block=32, partition=0 Mar 9 22:24:41 squish kernel: UDF-fs DEBUG super.c:786:udf_load_fileset: Rootdir at block=64, partition=0 Mar 9 22:24:41 squish kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume '', timestamp 2002/03/08 18:35 (1ed4)
On Sat, 9 Mar 2002, Paul wrote:
Previously, using packet-2.4.18-pre4.patch, it worked, but I would get loads of these messages:
Feb 20 21:29:27 squish kernel: Device 0b:00 not ready: cmd=0, sector=10124, nr_sectors=116 ...
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
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 ;-)
The driver determines the read/write speed of the drive as 12/8, though the drive is only supposed to be able to do speed 4 on cdrw media. (32/8/4)
I think the read/write speeds are reported incorrectly in some cases. This is harmless though.
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. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
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
Hello, Just to let you know. I had the same problem as Paul (set@pobox.com) and your patch solved it for me too. paulo -- Paulo José da Silva e Silva Professor Assistente do Dep. de Ciência da Computação (Assistant Professor of the Computer Science Dept.) Universidade de São Paulo - Brazil e-mail: rsilva@ime.usp.br Web: http://www.ime.usp.br/~rsilva Teoria é o que não entendemos o (Theory is something we don't) suficiente para chamar de prática. (understand well enough to call practice)
On Sun, Mar 10, 2002 at 05:46:19PM +0100, Peter Osterlund wrote:
On Sat, 9 Mar 2002, Paul wrote:
Previously, using packet-2.4.18-pre4.patch, it worked, but I would get loads of these messages:
Feb 20 21:29:27 squish kernel: Device 0b:00 not ready: cmd=0, sector=10124, nr_sectors=116 ...
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
I still get scsi timeouts with the timeout set to 20*HZ. Increasing it to 60*HZ got a large write to complete. I'd assume the required value would actually be based on the cache size of the drive and the write speed. (a huge cache writing at 1x being the worst case). Ben
On Mon, 18 Mar 2002, Ben Fennema wrote:
I still get scsi timeouts with the timeout set to 20*HZ. Increasing it to 60*HZ got a large write to complete. I'd assume the required value would actually be based on the cache size of the drive and the write speed. (a huge cache writing at 1x being the worst case).
Also, if the different packets in the write cache are not adjacent to each other, I guess an extra performance hit is taken. Otherwise, even at 1x you ought to be able to write 3MB in 20s. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (11)
-
Ben Fennema -
Ben Fennema -
Cory Bell -
Jeff Voskamp -
Jens Axboe -
Paul -
Paulo Jose da Silva e Silva -
Peter Osterlund -
Raphael Derosso Pereira - DephiNit -
Sergiy Kudryk -
Todd Tolliver