linux/block, branch v2.6.20-rc6

[PATCH] elevator: move clearing of unplug flag earlier

2007-01-23T19:01:17Z

A flag was recently added to the elevator code to avoid performing an unplug when reuests are being re-queued. The goal of this flag was to avoid a deep recursion that can occur when re-queueing requests after a SCSI device/host reset. See http://lkml.org/lkml/2006/5/17/254 However, that fix added the flag near the bottom of a case statement, where an earlier break (in an if statement) could transport one out of the case, without setting the flag. This patch sets the flag earlier in the case statement. I re-discovered the deep recursion recently during testing; I was told that it was a known problem, and the fix to it was in the kernel I was testing. Indeed it was ... but it didn't fix the bug. With the patch below, I no longer see the bug. Signed-off by: Linas Vepstas Signed-off-by: Jens Axboe Cc: Chris Wright Signed-off-by: Linus Torvalds

[PATCH] cfq-iosched: merging problem

2007-01-02T17:46:16Z

Two issues: - The final return 1 should be a return 0, otherwise comparing cfqq is a noop. - bio_sync() only checks the sync flag, while rq_is_sync() checks both for READ and sync. The latter is what we want. Expand the bio check to include reads, and relax the restriction to allow merging of async io into sync requests. In the future we want to clean up the SYNC logic, right now it means both sync request (such as READ and O_DIRECT WRITE) and unplug-on-issue. Leave that for later. Signed-off-by: Jens Axboe Signed-off-by: Linus Torvalds

[PATCH] cfq-iosched: tighten allow merge criteria

2006-12-22T22:13:08Z

The logic in cfq_allow_merge() wasn't clear enough - basically allow merging for the same queues only. Do a fast check for 'rq and bio both sync/async' before doing the cfqq hash lookup. This is verified to work with the fixed elv_try_merge() from commit bb4067e34159648d394943d5e2a011f838bff22f. Signed-off-by: Jens Axboe Signed-off-by: Linus Torvalds

[PATCH] fix kernel-doc warnings in 2.6.20-rc1

2006-12-22T16:55:47Z

Fix kernel-doc warnings in 2.6.20-rc1. Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] elevator: fixup typo in merge logic

2006-12-22T06:01:04Z

The recent io scheduler allow_merge commit left the block layer with no merging, oops. This patch fixes that up. That means the CFQ change needs to be verified again, it might not fix the original bug now. But that's a seperate thing, I'll double check that tomorrow. Signed-off-by: Jens Axboe Signed-off-by: Linus Torvalds

[PATCH] cfq-iosched: don't allow sync merges across queues

2006-12-20T10:04:12Z

Currently we allow any merge, even if the io originates from different processes. This can cause really bad starvation and unfairness, if those ios happen to be synchronous (reads or direct writes). So add a allow_merge hook to the io scheduler ops, so an io scheduler can help decide whether a bio/process combination may be merged with an existing request. Signed-off-by: Jens Axboe

[PATCH] Fixup blk_rq_unmap_user() API

2006-12-19T10:12:46Z

The blk_rq_unmap_user() API is not very nice. It expects the caller to know that rq->bio has to be reset to the original bio, and it will silently do nothing if that is not done. Instead make it explicit that we need to pass in the first bio, by expecting a bio argument. Signed-off-by: Jens Axboe

[PATCH] __blk_rq_unmap_user() fails to return error

2006-12-19T10:07:59Z

If the bio is user copied, the copy back could return -EFAULT. Make sure we return any error seen during unmapping. Signed-off-by: Jens Axboe

[PATCH] __blk_rq_map_user() doesn't need to grab the queue_lock

2006-12-19T07:34:17Z

It was for driver private back_merge_fn hooks, but they don't exist anymore. Signed-off-by: Jens Axboe

[PATCH] Remove queue merging hooks

2006-12-19T07:33:11Z

We have full flexibility of merging parameters now, so we can remove the hooks that define back/front/request merge strategies. Nobody is using them anymore. Signed-off-by: Jens Axboe