On Sat, Sep 09 2000, adam@cfar.umd.edu wrote:
however the write would freeze machien for seconds (as long as 30 sec or even min at time) not even mouse would move then.
Just a heads up on this bug, I've fixed it now. The problem was that cd-rw is a slow writer, as compared to a hard drive. I've maintained a patch on the side for the regular kernel, that batches freeing of requests once they are completed. That means once the request free list is empty, we wait until a certain fraction of the total requests are available before waking anyone up and handing them a free slot. This works well when a queue is under pressure because it provides some rudimentary flow control and allows the elevator to do a better job at merging new buffers. Back to the point -- for cd-rw, completing 16 requests can take a _lot_ of time. During this time, kflushd and kupdated would often be stuck for long periods of time waiting for a slot. No buffers could thus be flushed. Eek. For packet writing, we now wake for every free. There are still some stalls because it is slow (try using a dvd-ram, you'll see the same behaviour). But the stalls are much smaller now, around one second every once in a while. Hopefully I can fix this too.
- the data written onto cd is corrupted. for example
And a second heads up, I think I've nailed this one as well. I need
to do some more testing to be sure, though.
Unrelated info -- there's a rather severe bug in 0.0.2c that causes
buffers written to cd-rw not to be freed. Pretty stupid one too, the
folks on low memory machines will surely notice. A quick fix for that
is to move the atomic_inc(&bh->b_state) in the pkt_init_bh function
inside the if (bh->b_private == pd):
if (bh->b_private == pd) {
atomic_inc(&bh->b_count);
bh->b_end_io = pkt_end_io_write;
}
--
* Jens Axboe