diff options
author | Josef Bacik <jbacik@redhat.com> | 2008-10-29 14:49:05 -0400 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2008-10-29 14:49:05 -0400 |
commit | 2517920135b0d29e70453e5b03d70d7b94207df3 (patch) | |
tree | e0c526faa5c2c7bc3add340e5b7e8df26924dca9 /lib/bcd.c | |
parent | 80eb234af09dbe6c97b2e3d60a13ec391e98fbba (diff) | |
download | op-kernel-dev-2517920135b0d29e70453e5b03d70d7b94207df3.zip op-kernel-dev-2517920135b0d29e70453e5b03d70d7b94207df3.tar.gz |
Btrfs: nuke fs wide allocation mutex V2
This patch removes the giant fs_info->alloc_mutex and replaces it with a bunch
of little locks.
There is now a pinned_mutex, which is used when messing with the pinned_extents
extent io tree, and the extent_ins_mutex which is used with the pending_del and
extent_ins extent io trees.
The locking for the extent tree stuff was inspired by a patch that Yan Zheng
wrote to fix a race condition, I cleaned it up some and changed the locking
around a little bit, but the idea remains the same. Basically instead of
holding the extent_ins_mutex throughout the processing of an extent on the
extent_ins or pending_del trees, we just hold it while we're searching and when
we clear the bits on those trees, and lock the extent for the duration of the
operations on the extent.
Also to keep from getting hung up waiting to lock an extent, I've added a
try_lock_extent so if we cannot lock the extent, move on to the next one in the
tree and we'll come back to that one. I have tested this heavily and it does
not appear to break anything. This has to be applied on top of my
find_free_extent redo patch.
I tested this patch on top of Yan's space reblancing code and it worked fine.
The only thing that has changed since the last version is I pulled out all my
debugging stuff, apparently I forgot to run guilt refresh before I sent the
last patch out. Thank you,
Signed-off-by: Josef Bacik <jbacik@redhat.com>
Diffstat (limited to 'lib/bcd.c')
0 files changed, 0 insertions, 0 deletions