From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
To: Josef Bacik <jbacik@fb.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: fix joining same transaction handle more than twice
Date: Fri, 14 Mar 2014 20:04:15 +0800 [thread overview]
Message-ID: <5322F03F.50703@cn.fujitsu.com> (raw)
In-Reply-To: <5321BB2C.5000202@fb.com>
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
>
prev parent reply other threads:[~2014-03-14 12:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5322F03F.50703@cn.fujitsu.com \
--to=wangsl.fnst@cn.fujitsu.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.