Displaying 3 results from an estimated 3 matches for "add_tree_block".
Did you mean:
__add_tree_block
2012 Dec 19
6
HIT WARN_ON WARNING: at fs/btrfs/extent-tree.c:6339 btrfs_alloc_free_block+0x126/0x330 [btrfs]()
Hi all,
Did someone have met this problem before. When doing the tests, I hit
the WARN_ON. Is this log make sense or someone had fixed the problem.
If needed, I can supply the detail log and the testcase source file.
Version: the latest codes at linus git tree.
[ 2140.981293] use_block_rsv: 336 callbacks suppressed
[ 2140.981295] ------------[ cut here ]------------
[ 2140.981308]
2010 Jun 10
0
[PATCH] [12/23] BTRFS: Clean up unused variables -- bugs
...see comments for btrfs_del_dir_entries_in_log */
Index: linux-2.6.35-rc2-gcc/fs/btrfs/relocation.c
===================================================================
--- linux-2.6.35-rc2-gcc.orig/fs/btrfs/relocation.c
+++ linux-2.6.35-rc2-gcc/fs/btrfs/relocation.c
@@ -3098,6 +3098,8 @@ static int add_tree_block(struct reloc_c
BUG_ON(item_size != sizeof(struct btrfs_extent_item_v0));
ret = get_ref_objectid_v0(rc, path, extent_key,
&ref_owner, NULL);
+ if (ret < 0)
+ return ret;
BUG_ON(ref_owner >= BTRFS_MAX_LEVEL);
level = (int)ref_owner;
/* FIXME: get real generation */...
2011 Oct 04
68
[patch 00/65] Error handling patchset v3
Hi all -
Here''s my current error handling patchset, against 3.1-rc8. Almost all of
this patchset is preparing for actual error handling. Before we start in
on that work, I''m trying to reduce the surface we need to worry about. It
turns out that there is a ton of code that returns an error code but never
actually reports an error.
The patchset has grown to 65 patches. 46 of them