search for: btrfs_search_slot

When testing out 16KB blocks with direct I/O [1] on 3.3-rc6, we quickly see btrfs_search_slot returning positive numbers, popping an assertion [2]. Are >4KB block sizes known broken for now? Thanks, Daniel --- [1] mkfs.btrfs -m raid1 -d raid1 -l 16k -n 16k /dev/sda /dev/sdb mount /dev/sda /store && cd /store fio /usr/share/doc/fio/examples/iometer-file-access-server --- [2...

I''ve been watching how many btrfs_search_slot()''s we do and I noticed that when we create a file with selinux enabled we were doing 2 each time we initialize the security context. That''s because we lookup the xattr first so we can delete it if we''re setting a new value to an existing xattr. But in the create case w...

...FS_I(dir)->root; + struct btrfs_key key; + struct btrfs_path *path; + struct extent_buffer *leaf; + u32 nritems; + int slot; + u64 objectid; + int ret; + + path = btrfs_alloc_path(); + + key.objectid = dir->i_ino; + btrfs_set_key_type(&key, BTRFS_INODE_REF_KEY); + key.offset = 0; + ret = btrfs_search_slot(NULL, root, &key, path, 0, 0); + BUG_ON(ret == 0); + ret = 0; + + leaf = path->nodes[0]; + slot = path->slots[0]; + nritems = btrfs_header_nritems(leaf); + if (slot >= nritems) { + goto out; + } + + btrfs_item_key_to_cpu(leaf, &key, slot); + if (key.objectid != dir->i_ino || +...

...uffer''s level is below the level we must lock. and so on. And beside that, if we can not find the item, and the slot points to the first the item or the last item in the leaf, we must jump out the cached extent buffer search, and do the common search. - After the common search (use btrfs_search_slot), we will cache the leaf or the level-1 node into the btrfs i-node object. I have done small file performance (inline file) by sysbench and file creation test by fs_mark for the patch, and found it can make btrfs 5% ~ 16% faster. I think as the tree becomes deeper, the performance improvement o...

...sizeof(unaligned)); + k = &unaligned; + } + } + + BUG_ON(comp_keys(k, key) != 0); + *slot = 0; + + return 0; +} + /* * look for key in the tree. path is filled in with nodes along the way * if key is found, we return zero and you can find the item in the leaf @@ -2454,6 +2507,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root int write_lock_level = 0; u8 lowest_level = 0; int min_write_lock_level; + int prev_cmp; lowest_level = p->lowest_level; WARN_ON(lowest_level && ins_len > 0); @@ -2484,6 +2538,7 @@ int btrfs_search_slot(struct btrfs_trans...

Here's a patch against the unstable tree that gets the code to build against Linus's current tree (2.6.24-git12). This is needed as the kobject/kset api has changed there. I tried to make the smallest changes needed, and it builds and loads successfully, but I don't have a btrfs volume anywhere (yet) to try to see if things still work properly :) Signed-off-by: Greg Kroah-Hartman

...nux-2.6.38.new/fs/btrfs/disk-io.c 2011-03-23 11:44:39.000000000 +0900 @@ -1160,7 +1160,10 @@ struct btrfs_root *btrfs_read_fs_root_no root, fs_info, location->objectid); path = btrfs_alloc_path(); - BUG_ON(!path); + if (!path) { + kfree(root); + return ERR_PTR(-ENOMEM); + } ret = btrfs_search_slot(NULL, tree_root, location, path, 0, 0); if (ret == 0) { l = path->nodes[0]; diff -urNp linux-2.6.38/fs/btrfs/extent-tree.c linux-2.6.38.new/fs/btrfs/extent-tree.c --- linux-2.6.38/fs/btrfs/extent-tree.c 2011-03-15 10:20:32.000000000 +0900 +++ linux-2.6.38.new/fs/btrfs/extent-tree.c 2011-03-...

It''s been nearly a year since the patches needed to implement a reflinked copy between subvolumes have been posted (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865 ) and I still get "Invalid cross-device link" error with Linux 3.2.4 while I try to do a cp --reflink between subvolumes. This is a *very* useful feature to have (think offline file-level

...-tree.c +++ b/extent-tree.c @@ -115,7 +115,8 @@ static int cache_block_group(struct btrfs_root *root, last = max_t(u64, block_group->key.objectid, BTRFS_SUPER_INFO_OFFSET); key.objectid = last; key.offset = 0; - btrfs_set_key_type(&key, BTRFS_EXTENT_ITEM_KEY); + key.type = 0; + ret = btrfs_search_slot(NULL, root, &key, path, 0, 0); if (ret < 0) goto err; @@ -142,14 +143,18 @@ static int cache_block_group(struct btrfs_root *root, break; } - if (btrfs_key_type(&key) == BTRFS_EXTENT_ITEM_KEY) { + if (key.type == BTRFS_EXTENT_ITEM_KEY || + key.type == BTRFS_METADATA_I...

...d8 ffff8801dbd5c280 [36700.671670] Call Trace: [36700.671672] [<ffffffff816f36b9>] schedule+0x29/0x70 [36700.671679] [<ffffffffa05d9b0d>] btrfs_tree_lock+0x6d/0x230 [btrfs] [36700.671680] [<ffffffff81066760>] ? add_wait_queue+0x60/0x60 [36700.671685] [<ffffffffa0582829>] btrfs_search_slot+0x999/0xb00 [btrfs] [36700.671691] [<ffffffffa05bd9de>] ? btrfs_lookup_first_ordered_extent+0x5e/0xb0 [btrfs] [36700.671698] [<ffffffffa05e3e54>] __btrfs_write_out_cache+0x8c4/0xa80 [btrfs] [36700.671704] [<ffffffffa05e4362>] btrfs_write_out_cache+0xb2/0xf0 [btrfs] [36700.67171...

...ree_block+0x9f/0x220 [btrfs] [ 386.318408] [<ffffffffa00c83b2>] __btrfs_cow_block+0x122/0x4f0 [btrfs] [ 386.318415] [<ffffffff8169e00e>] ? _raw_spin_lock+0xe/0x20 [ 386.318443] [<ffffffffa00c887c>] btrfs_cow_block+0xfc/0x220 [btrfs] [ 386.318472] [<ffffffffa00cc9f8>] btrfs_search_slot+0x368/0x740 [btrfs] [ 386.318502] [<ffffffffa00d32de>] lookup_inline_extent_backref+0x8e/0x4c0 [btrfs] [ 386.318532] [<ffffffffa00d3770>] lookup_extent_backref+0x60/0xf0 [btrfs] [ 386.318561] [<ffffffffa00d5c55>] __btrfs_free_extent+0xb5/0x670 [btrfs] [ 386.318592] [<ff...

...t;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] [<ffffffffa032d201>] ? btrfs_find_ref_cluster+0xd/0x13c [btrfs] [<ffffffffa02e9fd6>] ? btrfs_run_delayed_refs+0xd1/0x17c [b...

Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:12 mail kernel: [13559.089834] parent transid verify failed on 3062073683968 wanted 5181 found 5188

...22 09:23:57 bigbox kernel: ] [<ffffffff812c0f97>] read_block_for_search+0x117/0x3d0 May 22 09:23:57 bigbox kernel: 32559] [<ffffffff812c0857>] ? generic_bin_search.constprop.4+0[<ffffffff812be27d>] ? unlock_up+0x15d/0x190 May 22 09:23:57 bigbox kernel: [56455.5ffff812c31c1>] btrfs_search_slot+0x241/0x720 May 22 09:23:57 bigbox kernel: [56455.5326fff812c3adc>] btrfs_search_slot_for_inode+0x43c/0x910 May 22 09:23:57 bigbox kernel: [56455.532fffffff812d5f04>] btrfs_lookup_file_extent+0x54/0x70 May 22 09:23:57 bigbox kernel: [56455.532646ffff812f097c>] btrfs_drop_extents+0xec/0x940...

We''re going to use this flag EXTENT_DEFRAG to indicate which range belongs to defragment so that we can implement snapshow-aware defrag: We set the EXTENT_DEFRAG flag when dirtying the extents that need defragmented, so later on writeback thread can differentiate between normal writeback and writeback started by defragmentation. This patch is used for the latter one. Originally patch

A user has encountered a NULL pointer kernel oops in btrfs when encountering media errors. The problem has been identified as an unhandled NULL pointer returned from find_get_page(). This modification simply checks for a NULL page, and returns with an error if found (the extent_range_uptodate() function returns 1 on errors). After testing this patch, the user reported that the error with the

...gt;] warn_slowpath_common+0x79/0xc0 [ 347.237720] [<ffffffff8122c889>] btrfs_alloc_free_block+0x399/0x3a0 [ 347.237725] [<ffffffff81218617>] __btrfs_cow_block+0x137/0x550 [ 347.237728] [<ffffffff81218baf>] btrfs_cow_block+0xff/0x250 [ 347.237731] [<ffffffff8121d2f1>] btrfs_search_slot+0x421/0x980 [ 347.237735] [<ffffffff8127fa0e>] do_relocation+0x3be/0x510 [ 347.237740] [<ffffffff812839f3>] relocate_tree_blocks+0x5e3/0x610 [ 347.237743] [<ffffffff812849a4>] relocate_block_group+0x444/0x6c0 [ 347.237747] [<ffffffff81284dc9>] btrfs_relocate_block_gr...

...key.type = BTRFS_EXTENT_REF_KEY; - key.offset = parent; + if (parent) { + key.type = BTRFS_SHARED_DATA_REF_KEY; + key.offset = parent; + } else { + key.type = BTRFS_EXTENT_DATA_REF_KEY; + key.offset = hash_extent_data_ref(root_objectid, + owner, offset); + } +again: + recow = 0; + ret = btrfs_search_slot(trans, root, &key, path, -1, 1); + if (ret < 0) { + err = ret; + goto fail; + } - ret = btrfs_search_slot(trans, root, &key, path, del ? -1 : 0, 1); - if (ret < 0) - goto out; - if (ret > 0) { - ret = -ENOENT; - goto out; + if (parent) { + if (ret > 0) + goto fail; +...

Hello, When drop_progress isn't zero, the root->node's usage count is increased in btrfs_search_slot. Therefore, the get_bh in the body of while loop is redundant in most cases. (this change is in accordance with btrfs_defrag_leaves). The second change is decrease root->node's usage count when drop a snapshot. Regards YZ diff -r 29b8cc7794ac extent-tree.c --- a/extent-tree.c Thu Sep 20 1...

...n_lock+0x2a/0x89 [btrfs] [ 1998.478275] [<ffffffff81468ad3>] _raw_spin_lock+0x36/0x69 [ 1998.478275] [<ffffffffa025dbe1>] ? btrfs_try_spin_lock+0x2a/0x89 [btrfs] [ 1998.478275] [<ffffffffa025dbe1>] btrfs_try_spin_lock+0x2a/0x89 [btrfs] [ 1998.478275] [<ffffffffa021d025>] btrfs_search_slot+0x39c/0x4c0 [btrfs] [ 1998.478275] [<ffffffffa022a7c9>] btrfs_lookup_xattr+0x76/0xd7 [btrfs] [ 1998.478275] [<ffffffffa0219290>] ? btrfs_alloc_path+0x1a/0x1c [btrfs] [ 1998.478275] [<ffffffff81114a76>] ? kmem_cache_alloc+0x57/0xfc [ 1998.478275] [<ffffffffa0240d00>] ? bt...