search for: find_free_extent

...258 +++++++++++++++++------------------------------- 1 files changed, 90 insertions(+), 168 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 26fec19..3e9b675 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -2552,14 +2552,10 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, struct btrfs_root *root = orig_root->fs_info->extent_root; u64 total_needed = num_bytes; u64 *last_ptr = NULL; - u64 last_wanted = 0; struct btrfs_block_group_cache *block_group = NULL; - int chunk_alloc_done = 0; int empty_cluster = 2 * 1024 * 1024...

Hello, This patch adds a new parameter 'full_scan' to 'find_search_start', thereby 'find_search_start' can know whether 'find_free_extent' is in full scan phrase. I feel that 'find_search_start' should skip calling 'btrfs_find_block_group' when 'find_free_extent' is in full scan phrase. In my test on a 2GB volume, Oops occurs when space usage is about 76%. After apply the patch, Oops occurs when space usa...

...p_bits() won''t match and we''ll go to choose another block group. However because search_start matches orig_search_start we go to see if we can allocate a chunk. If we are in the situation that we cannot allocate a chunk, we fail and ENOSPC. This is kind of a big flaw of the way find_free_extent works, as it along with find_free_space loop through _all_ of the block groups, not just the ones that we want to allocate out of. This patch completely kills find_free_space and rolls it into find_free_extent. I''ve introduced a sort of state machine into this, which will make it easier...

..., It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows block_group = btrfs_lookup_block_group(root->fs_info, ins->objectid); cache_block_group(block_group); btrfs_lookup_block_group releases a spin_lock at the end so the writes in spin_lock cannot get out. Another thing is that...

...Josef Bacik <jbacik@redhat.com> Index: root/btrfs-unstable/fs/btrfs/extent-tree.c =================================================================== --- root.orig/btrfs-unstable/fs/btrfs/extent-tree.c +++ root/btrfs-unstable/fs/btrfs/extent-tree.c @@ -2238,7 +2238,10 @@ static int noinline find_free_extent(str total_needed += empty_size; new_group: - block_group = btrfs_lookup_first_block_group(info, search_start); + block_group = btrfs_lookup_block_group(info, search_start); + if (!block_group) + block_group = btrfs_lookup_first_block_group(info, + search_start); /* * Ok this...

...s to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and in commit path via commit_cowonly_roots(). This patch is an RFC, that attempts to fix this problem, by notifying the caching threads to give up on extent_commit_sem. On a system with a lot of metadata (~20Gb total metadata, ~10Gb extent tree), with increased number of caching_threads, commi...

...+0x18f/0x1b8 [btrfs] [515954.295050] [<ffffffff8103ce8e>] ? need_resched+0x23/0x2d [515954.295050] [<ffffffff81103ccd>] ? kmem_cache_alloc+0x94/0x105 [515954.295050] [<ffffffffa0329ff7>] ? btrfs_find_space_cluster+0xce/0x189 [btrfs] [515954.295050] [<ffffffffa02eaaa0>] ? find_free_extent.clone.64+0x549/0x8c7 [btrfs] [515954.295050] [<ffffffffa032765e>] ? tree_search_offset+0x18f/0x1b8 [btrfs] [515954.295050] [<ffffffffa02eb745>] ? btrfs_reserve_extent+0xb0/0x190 [btrfs] [515954.295050] [<ffffffffa02ebdfc>] ? btrfs_alloc_free_block+0x22e/0x349 [btrfs] [515954.29...

...00000000002af5c0: b9020011 ltgr %r1,%r1 [ 121.451199] 00000000002af5c4: a7a40005 brc 10,2af5ce [ 121.451226] 00000000002af5c8: c0f400000790 brcl 15,2b04e8 [ 121.451245] Call Trace: [ 121.451255] ([<000003e000715e3e>] find_free_extent+0x236/0x784 [btrfs]) [ 121.451396] [<000003e0007164f0>] __btrfs_reserve_extent+0x164/0x314 [btrfs] [ 121.451489] [<000003e0007184e2>] btrfs_alloc_extent+0x4e/0xc8 [btrfs] [ 121.451583] [<000003e0007185c8>] btrfs_alloc_free_block+0x6c/0xb0 [btrfs] [ 121.451676] [<000003e...

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

...K_GROUP_RAID1; @@ -2691,7 +2701,6 @@ static u64 btrfs_get_alloc_profile(struct btrfs_root *root, u64 data) info->metadata_alloc_profile; data = BTRFS_BLOCK_GROUP_METADATA | alloc_profile; } - return btrfs_reduce_alloc_profile(root, data); } @@ -3635,7 +3644,7 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, u64 search_start, u64 search_end, u64 hint_byte, struct btrfs_key *ins, u64 exclude_start, u64 exclude_nr, - int data) + u64 data) { int ret = 0; struct btrfs_root *root = orig_root->fs_info->extent_root; @@...

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

...*/ - if (flags & BTRFS_BLOCK_GROUP_DATA) { + if (flags & BTRFS_BLOCK_GROUP_DATA && fs_info->metadata_ratio) { fs_info->data_chunk_allocations++; if (!(fs_info->data_chunk_allocations % fs_info->metadata_ratio)) @@ -3737,7 +3723,7 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, space_info = __find_space_info(root->fs_info, data); - if (orig_root->ref_cows || empty_size) + if ((orig_root->ref_cows || empty_size) && !trans->is_relocate) allowed_chunk_alloc = 1; if (data & BTRFS_BLOCK_GROUP_METADATA) { @@...