* [PATCH] Btrfs: fix joining same transaction handle more than twice
@ 2014-03-13 5:19 Wang Shilong
2014-03-13 14:05 ` Josef Bacik
0 siblings, 1 reply; 3+ messages in thread
From: Wang Shilong @ 2014-03-13 5:19 UTC (permalink / raw)
To: linux-btrfs
We hit something like the following function call flows:
|->run_delalloc_range()
|->btrfs_join_transaction()
|->cow_file_range()
|->btrfs_join_transaction()
|->find_free_extent()
|->btrfs_join_transaction()
Trace infomation can be seen as:
[ 7411.127040] ------------[ cut here ]------------
[ 7411.127060] WARNING: CPU: 0 PID: 11557 at fs/btrfs/transaction.c:383 start_transaction+0x561/0x580 [btrfs]()
[ 7411.127079] CPU: 0 PID: 11557 Comm: kworker/u8:9 Tainted: G O 3.13.0+ #4
[ 7411.127080] Hardware name: LENOVO QiTianM4350/ , BIOS F1KT52AUS 05/24/2013
[ 7411.127085] Workqueue: writeback bdi_writeback_workfn (flush-btrfs-5)
[ 7411.127092] Call Trace:
[ 7411.127097] [<ffffffff815b87b0>] dump_stack+0x45/0x56
[ 7411.127101] [<ffffffff81051ffd>] warn_slowpath_common+0x7d/0xa0
[ 7411.127102] [<ffffffff810520da>] warn_slowpath_null+0x1a/0x20
[ 7411.127109] [<ffffffffa0444fb1>] start_transaction+0x561/0x580 [btrfs]
[ 7411.127115] [<ffffffffa0445027>] btrfs_join_transaction+0x17/0x20 [btrfs]
[ 7411.127120] [<ffffffffa0431c91>] find_free_extent+0xa21/0xb50 [btrfs]
[ 7411.127126] [<ffffffffa0431f68>] btrfs_reserve_extent+0xa8/0x1a0 [btrfs]
[ 7411.127131] [<ffffffffa04322ce>] btrfs_alloc_free_block+0xee/0x440 [btrfs]
[ 7411.127137] [<ffffffffa043bd6e>] ? btree_set_page_dirty+0xe/0x10 [btrfs]
[ 7411.127142] [<ffffffffa041da51>] __btrfs_cow_block+0x121/0x530 [btrfs]
[ 7411.127146] [<ffffffffa041dfff>] btrfs_cow_block+0x11f/0x1c0 [btrfs]
[ 7411.127151] [<ffffffffa0421b74>] btrfs_search_slot+0x1d4/0x9c0 [btrfs]
[ 7411.127157] [<ffffffffa0438567>] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
[ 7411.127163] [<ffffffffa0456bfc>] __btrfs_drop_extents+0x16c/0xd90 [btrfs]
[ 7411.127169] [<ffffffffa0444ae3>] ? start_transaction+0x93/0x580 [btrfs]
[ 7411.127171] [<ffffffff811663e2>] ? kmem_cache_alloc+0x132/0x140
[ 7411.127176] [<ffffffffa041cd9a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
[ 7411.127182] [<ffffffffa044aa61>] cow_file_range_inline+0x181/0x2e0 [btrfs]
[ 7411.127187] [<ffffffffa044aead>] cow_file_range+0x2ed/0x440 [btrfs]
[ 7411.127194] [<ffffffffa0464d7f>] ? free_extent_buffer+0x4f/0xb0 [btrfs]
[ 7411.127200] [<ffffffffa044b38f>] run_delalloc_nocow+0x38f/0xa60 [btrfs]
[ 7411.127207] [<ffffffffa0461600>] ? test_range_bit+0x30/0x180 [btrfs]
[ 7411.127212] [<ffffffffa044bd48>] run_delalloc_range+0x2e8/0x350 [btrfs]
[ 7411.127219] [<ffffffffa04618f9>] ? find_lock_delalloc_range+0x1a9/0x1e0 [btrfs]
[ 7411.127222] [<ffffffff812a1e71>] ? blk_queue_bio+0x2c1/0x330
[ 7411.127228] [<ffffffffa0462ad4>] __extent_writepage+0x2f4/0x760 [btrfs]
Here we fix it by avoiding joining transaction again if we have held
a transaction handle when allocating chunk in find_free_extent().
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index da8031b..06066d5 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6604,8 +6604,14 @@ loop:
loop++;
if (loop == LOOP_ALLOC_CHUNK) {
struct btrfs_trans_handle *trans;
+ int exist = 0;
+
+ trans = current->journal_info;
+ if (trans)
+ exist = 1;
+ else
+ trans = btrfs_join_transaction(root);
- trans = btrfs_join_transaction(root);
if (IS_ERR(trans)) {
ret = PTR_ERR(trans);
goto out;
@@ -6622,7 +6628,8 @@ loop:
root, ret);
else
ret = 0;
- btrfs_end_transaction(trans, root);
+ if (!exist)
+ btrfs_end_transaction(trans, root);
if (ret)
goto out;
}
--
1.9.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Btrfs: fix joining same transaction handle more than twice
2014-03-13 5:19 [PATCH] Btrfs: fix joining same transaction handle more than twice Wang Shilong
@ 2014-03-13 14:05 ` Josef Bacik
2014-03-14 12:04 ` Wang Shilong
0 siblings, 1 reply; 3+ messages in thread
From: Josef Bacik @ 2014-03-13 14:05 UTC (permalink / raw)
To: Wang Shilong, linux-btrfs
On 03/13/2014 01:19 AM, Wang Shilong wrote:
> We hit something like the following function call flows:
>
> |->run_delalloc_range()
> |->btrfs_join_transaction()
> |->cow_file_range()
> |->btrfs_join_transaction()
> |->find_free_extent()
> |->btrfs_join_transaction()
>
> Trace infomation can be seen as:
>
> [ 7411.127040] ------------[ cut here ]------------
> [ 7411.127060] WARNING: CPU: 0 PID: 11557 at fs/btrfs/transaction.c:383 start_transaction+0x561/0x580 [btrfs]()
> [ 7411.127079] CPU: 0 PID: 11557 Comm: kworker/u8:9 Tainted: G O 3.13.0+ #4
> [ 7411.127080] Hardware name: LENOVO QiTianM4350/ , BIOS F1KT52AUS 05/24/2013
> [ 7411.127085] Workqueue: writeback bdi_writeback_workfn (flush-btrfs-5)
> [ 7411.127092] Call Trace:
> [ 7411.127097] [<ffffffff815b87b0>] dump_stack+0x45/0x56
> [ 7411.127101] [<ffffffff81051ffd>] warn_slowpath_common+0x7d/0xa0
> [ 7411.127102] [<ffffffff810520da>] warn_slowpath_null+0x1a/0x20
> [ 7411.127109] [<ffffffffa0444fb1>] start_transaction+0x561/0x580 [btrfs]
> [ 7411.127115] [<ffffffffa0445027>] btrfs_join_transaction+0x17/0x20 [btrfs]
> [ 7411.127120] [<ffffffffa0431c91>] find_free_extent+0xa21/0xb50 [btrfs]
> [ 7411.127126] [<ffffffffa0431f68>] btrfs_reserve_extent+0xa8/0x1a0 [btrfs]
> [ 7411.127131] [<ffffffffa04322ce>] btrfs_alloc_free_block+0xee/0x440 [btrfs]
> [ 7411.127137] [<ffffffffa043bd6e>] ? btree_set_page_dirty+0xe/0x10 [btrfs]
> [ 7411.127142] [<ffffffffa041da51>] __btrfs_cow_block+0x121/0x530 [btrfs]
> [ 7411.127146] [<ffffffffa041dfff>] btrfs_cow_block+0x11f/0x1c0 [btrfs]
> [ 7411.127151] [<ffffffffa0421b74>] btrfs_search_slot+0x1d4/0x9c0 [btrfs]
> [ 7411.127157] [<ffffffffa0438567>] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
> [ 7411.127163] [<ffffffffa0456bfc>] __btrfs_drop_extents+0x16c/0xd90 [btrfs]
> [ 7411.127169] [<ffffffffa0444ae3>] ? start_transaction+0x93/0x580 [btrfs]
> [ 7411.127171] [<ffffffff811663e2>] ? kmem_cache_alloc+0x132/0x140
> [ 7411.127176] [<ffffffffa041cd9a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
> [ 7411.127182] [<ffffffffa044aa61>] cow_file_range_inline+0x181/0x2e0 [btrfs]
> [ 7411.127187] [<ffffffffa044aead>] cow_file_range+0x2ed/0x440 [btrfs]
> [ 7411.127194] [<ffffffffa0464d7f>] ? free_extent_buffer+0x4f/0xb0 [btrfs]
> [ 7411.127200] [<ffffffffa044b38f>] run_delalloc_nocow+0x38f/0xa60 [btrfs]
> [ 7411.127207] [<ffffffffa0461600>] ? test_range_bit+0x30/0x180 [btrfs]
> [ 7411.127212] [<ffffffffa044bd48>] run_delalloc_range+0x2e8/0x350 [btrfs]
> [ 7411.127219] [<ffffffffa04618f9>] ? find_lock_delalloc_range+0x1a9/0x1e0 [btrfs]
> [ 7411.127222] [<ffffffff812a1e71>] ? blk_queue_bio+0x2c1/0x330
> [ 7411.127228] [<ffffffffa0462ad4>] __extent_writepage+0x2f4/0x760 [btrfs]
>
> Here we fix it by avoiding joining transaction again if we have held
> a transaction handle when allocating chunk in find_free_extent().
>
>
So I just put that warning there to see if we were ever embedding 3
joins at a time, not because it was an actual problem, I'd say just kill
the warning. Thanks,
Josef
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Btrfs: fix joining same transaction handle more than twice
2014-03-13 14:05 ` Josef Bacik
@ 2014-03-14 12:04 ` Wang Shilong
0 siblings, 0 replies; 3+ messages in thread
From: Wang Shilong @ 2014-03-14 12:04 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs
On 03/13/2014 10:05 PM, Josef Bacik wrote:
> On 03/13/2014 01:19 AM, Wang Shilong wrote:
>> We hit something like the following function call flows:
>>
>> |->run_delalloc_range()
>> |->btrfs_join_transaction()
>> |->cow_file_range()
>> |->btrfs_join_transaction()
>> |->find_free_extent()
>> |->btrfs_join_transaction()
>>
>> Trace infomation can be seen as:
>>
>> [ 7411.127040] ------------[ cut here ]------------
>> [ 7411.127060] WARNING: CPU: 0 PID: 11557 at fs/btrfs/transaction.c:383 start_transaction+0x561/0x580 [btrfs]()
>> [ 7411.127079] CPU: 0 PID: 11557 Comm: kworker/u8:9 Tainted: G O 3.13.0+ #4
>> [ 7411.127080] Hardware name: LENOVO QiTianM4350/ , BIOS F1KT52AUS 05/24/2013
>> [ 7411.127085] Workqueue: writeback bdi_writeback_workfn (flush-btrfs-5)
>> [ 7411.127092] Call Trace:
>> [ 7411.127097] [<ffffffff815b87b0>] dump_stack+0x45/0x56
>> [ 7411.127101] [<ffffffff81051ffd>] warn_slowpath_common+0x7d/0xa0
>> [ 7411.127102] [<ffffffff810520da>] warn_slowpath_null+0x1a/0x20
>> [ 7411.127109] [<ffffffffa0444fb1>] start_transaction+0x561/0x580 [btrfs]
>> [ 7411.127115] [<ffffffffa0445027>] btrfs_join_transaction+0x17/0x20 [btrfs]
>> [ 7411.127120] [<ffffffffa0431c91>] find_free_extent+0xa21/0xb50 [btrfs]
>> [ 7411.127126] [<ffffffffa0431f68>] btrfs_reserve_extent+0xa8/0x1a0 [btrfs]
>> [ 7411.127131] [<ffffffffa04322ce>] btrfs_alloc_free_block+0xee/0x440 [btrfs]
>> [ 7411.127137] [<ffffffffa043bd6e>] ? btree_set_page_dirty+0xe/0x10 [btrfs]
>> [ 7411.127142] [<ffffffffa041da51>] __btrfs_cow_block+0x121/0x530 [btrfs]
>> [ 7411.127146] [<ffffffffa041dfff>] btrfs_cow_block+0x11f/0x1c0 [btrfs]
>> [ 7411.127151] [<ffffffffa0421b74>] btrfs_search_slot+0x1d4/0x9c0 [btrfs]
>> [ 7411.127157] [<ffffffffa0438567>] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
>> [ 7411.127163] [<ffffffffa0456bfc>] __btrfs_drop_extents+0x16c/0xd90 [btrfs]
>> [ 7411.127169] [<ffffffffa0444ae3>] ? start_transaction+0x93/0x580 [btrfs]
>> [ 7411.127171] [<ffffffff811663e2>] ? kmem_cache_alloc+0x132/0x140
>> [ 7411.127176] [<ffffffffa041cd9a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
>> [ 7411.127182] [<ffffffffa044aa61>] cow_file_range_inline+0x181/0x2e0 [btrfs]
>> [ 7411.127187] [<ffffffffa044aead>] cow_file_range+0x2ed/0x440 [btrfs]
>> [ 7411.127194] [<ffffffffa0464d7f>] ? free_extent_buffer+0x4f/0xb0 [btrfs]
>> [ 7411.127200] [<ffffffffa044b38f>] run_delalloc_nocow+0x38f/0xa60 [btrfs]
>> [ 7411.127207] [<ffffffffa0461600>] ? test_range_bit+0x30/0x180 [btrfs]
>> [ 7411.127212] [<ffffffffa044bd48>] run_delalloc_range+0x2e8/0x350 [btrfs]
>> [ 7411.127219] [<ffffffffa04618f9>] ? find_lock_delalloc_range+0x1a9/0x1e0 [btrfs]
>> [ 7411.127222] [<ffffffff812a1e71>] ? blk_queue_bio+0x2c1/0x330
>> [ 7411.127228] [<ffffffffa0462ad4>] __extent_writepage+0x2f4/0x760 [btrfs]
>>
>> Here we fix it by avoiding joining transaction again if we have held
>> a transaction handle when allocating chunk in find_free_extent().
>>
>>
> So I just put that warning there to see if we were ever embedding 3
> joins at a time, not because it was an actual problem, I'd say just kill
> the warning. Thanks,
We need keep @orgin_rsv and restore it when ending transaction. So we'd
better
not embed more than 2 joins now.
Thanks,
Wang
>
> Josef
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-03-14 12:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-13 5:19 [PATCH] Btrfs: fix joining same transaction handle more than twice Wang Shilong
2014-03-13 14:05 ` Josef Bacik
2014-03-14 12:04 ` Wang Shilong
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.