search for: btrfs_try_spin_lock

...======== [ 1998.329940] [ INFO: possible recursive locking detected ] [ 1998.329940] 2.6.39+ #3 [ 1998.329940] --------------------------------------------- [ 1998.329940] dd/25718 is trying to acquire lock: [ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa025dbe1>] btrfs_try_spin_lock+0x2a/0x89 [btrfs] [ 1998.329940] [ 1998.329940] but task is already holding lock: [ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa025dbae>] btrfs_clear_lock_blocking+0x22/0x2b [btrfs] [ 1998.478275] [ 1998.478275] other info that might help us debug this: [ 1998....

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

...0644 --- a/fs/btrfs/locking.h +++ b/fs/btrfs/locking.h @@ -24,7 +24,7 @@ #define BTRFS_WRITE_LOCK_BLOCKING 3 #define BTRFS_READ_LOCK_BLOCKING 4 -int btrfs_tree_lock(struct extent_buffer *eb); +void btrfs_tree_lock(struct extent_buffer *eb); int btrfs_tree_unlock(struct extent_buffer *eb); int btrfs_try_spin_lock(struct extent_buffer *eb); diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index a1c9404..8f4d150 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -249,9 +249,9 @@ int btrfs_add_ordered_extent_compress(struct inode *inode, u64 file_offset, * when an ordered e...

This is a first draft of a subvolume quota implementation. It is possible to limit subvolumes and any group of subvolumes and also to track the amount of space that will get freed when deleting snapshots. The current version is functionally incomplete, with the main missing feature being the initial scan and rescan of an existing filesystem. I put some effort into writing an introduction into