Displaying 4 results from an estimated 4 matches for "btrfs_set_node_key".
2013 May 07
2
[PATCH] Btrfs: fix passing wrong arg gfp_t to decide the correct allocation mode
..._ON(ret < 0);
}
@@ -1886,7 +1885,7 @@ static noinline int balance_level(struct btrfs_trans_handle *trans,
struct btrfs_disk_key right_key;
btrfs_node_key(right, &right_key, 0);
tree_mod_log_set_node_key(root->fs_info, parent,
- pslot + 1, 0);
+ pslot + 1);
btrfs_set_node_key(parent, &right_key, pslot + 1);
btrfs_mark_buffer_dirty(parent);
}
@@ -1931,7 +1930,7 @@ static noinline int balance_level(struct btrfs_trans_handle *trans,
struct btrfs_disk_key mid_key;
btrfs_node_key(mid, &mid_key, 0);
tree_mod_log_set_node_key(root->fs_info, parent,
-...
2011 Sep 27
2
high CPU usage and low perf
...ffa02ebdfc>] ? btrfs_alloc_free_block+0x22e/0x349 [btrfs]
[<ffffffffa02dea3d>] ? __btrfs_cow_block+0x102/0x31e [btrfs]
[<ffffffffa02ebdfc>] ? btrfs_alloc_free_block+0x22e/0x349 [btrfs]
[<ffffffffa02dea3d>] ? __btrfs_cow_block+0x102/0x31e [btrfs]
[<ffffffffa02dd400>] ? btrfs_set_node_key+0x1a/0x20 [btrfs]
[<ffffffffa02ded5d>] ? btrfs_cow_block+0x104/0x14e [btrfs]
[<ffffffffa02e1c34>] ? btrfs_search_slot+0x162/0x4cb [btrfs]
[<ffffffffa02e2ea3>] ? btrfs_insert_empty_items+0x6a/0xba [btrfs]
[<ffffffffa02e9bf3>] ? run_clustered_refs+0x370/0x682 [btrfs]
[<...
2009 May 12
0
[PATCH 1/2] btrfs-progs: mixed back ref support
...,
level + 1);
if (wret)
ret = wret;
- ret = btrfs_update_ref(trans, root, c, split, 0, c_nritems - mid);
- BUG_ON(ret);
-
if (path->slots[level] >= mid) {
path->slots[level] -= mid;
free_extent_buffer(c);
@@ -1744,9 +1782,6 @@ static int push_leaf_right(struct btrfs_
btrfs_set_node_key(upper, &disk_key, slot + 1);
btrfs_mark_buffer_dirty(upper);
- ret = btrfs_update_ref(trans, root, left, right, 0, push_items);
- BUG_ON(ret);
-
/* then fixup the leaf pointer in the path */
if (path->slots[0] >= left_nritems) {
path->slots[0] -= left_nritems;
@@ -1907,10 +1...
2011 Jun 21
19
[GIT PULL v3] Btrfs: improve write ahead log with sub transaction
I''ve been working to try to improve the write-ahead log''s performance,
and I found that the bottleneck addresses in the checksum items,
especially when we want to make a random write on a large file, e.g a 4G file.
Then a idea for this suggested by Chris is to use sub transaction ids and just
to log the part of inode that had changed since either the last log commit or
the last