Btrfs: fix num_workers_starting bug and other bugs in async thread
authorJosef Bacik <josef@redhat.com>
Fri, 18 Nov 2011 19:37:27 +0000 (14:37 -0500)
committerJosef Bacik <josef@redhat.com>
Thu, 15 Dec 2011 16:04:21 +0000 (11:04 -0500)
commit0dc3b84a73267f47a75468f924f5d58a840e3152
tree0c2f64c2884a0de54e3fe15971e960f71a722afb
parent5dbc8fca8ef5d719014f22345d990e957dcfc692
Btrfs: fix num_workers_starting bug and other bugs in async thread

Al pointed out we have some random problems with the way we account for
num_workers_starting in the async thread stuff.  First of all we need to make
sure to decrement num_workers_starting if we fail to start the worker, so make
__btrfs_start_workers do this.  Also fix __btrfs_start_workers so that it
doesn't call btrfs_stop_workers(), there is no point in stopping everybody if we
failed to create a worker.  Also check_pending_worker_creates needs to call
__btrfs_start_work in it's work function since it already increments
num_workers_starting.

People only start one worker at a time, so get rid of the num_workers argument
everywhere, and make btrfs_queue_worker a void since it will always succeed.
Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>
fs/btrfs/async-thread.c
fs/btrfs/async-thread.h
fs/btrfs/disk-io.c
fs/btrfs/scrub.c