From: Liu Bo <bo.li.liu@oracle.com>
To: Mitch Harder <mitch.harder@sabayonlinux.org>
Cc: linux-btrfs@vger.kernel.org, dave@jikos.cz
Subject: Re: [PATCH 2/2 v3] Btrfs: snapshot-aware defrag
Date: Wed, 26 Sep 2012 09:07:53 +0800 [thread overview]
Message-ID: <50625569.9040102@oracle.com> (raw)
In-Reply-To: <CAKcLGm_4iUB1B8DPOx1D7i8eMa7po9fWFUYVOqp1N9nmZ1ExHQ@mail.gmail.com>
On 09/26/2012 01:39 AM, Mitch Harder wrote:
> On Mon, Sep 17, 2012 at 4:58 AM, Liu Bo <bo.li.liu@oracle.com> wrote:
>> This comes from one of btrfs's project ideas,
>> As we defragment files, we break any sharing from other snapshots.
>> The balancing code will preserve the sharing, and defrag needs to grow this
>> as well.
>>
>> Now we're able to fill the blank with this patch, in which we make full use of
>> backref walking stuff.
>>
>> Here is the basic idea,
>> o set the writeback ranges started by defragment with flag EXTENT_DEFRAG
>> o at endio, after we finish updating fs tree, we use backref walking to find
>> all parents of the ranges and re-link them with the new COWed file layout by
>> adding corresponding backrefs.
>>
>> Originally patch by Li Zefan <lizf@cn.fujitsu.com>
>> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
>
> I'm hitting the WARN_ON in record_extent_backrefs() indicating a
> problem with the return value from iterate_inodes_from_logical().
>
> [ 6865.184782] ------------[ cut here ]------------
> [ 6865.184819] WARNING: at fs/btrfs/inode.c:2062
> record_extent_backrefs+0xe5/0xe7 [btrfs]()
> [ 6865.184823] Hardware name: OptiPlex 745
> [ 6865.184825] Modules linked in: lpc_ich mfd_core xts gf128mul cryptd
> aes_x86_64 sha256_generic btrfs libcrc32c
> [ 6865.184841] Pid: 4239, comm: btrfs-endio-wri Not tainted 3.5.4-git-local+ #1
> [ 6865.184844] Call Trace:
> [ 6865.184856] [<ffffffff81031d6a>] warn_slowpath_common+0x74/0xa2
> [ 6865.184862] [<ffffffff81031db2>] warn_slowpath_null+0x1a/0x1c
> [ 6865.184884] [<ffffffffa003356b>] record_extent_backrefs+0xe5/0xe7 [btrfs]
> [ 6865.184908] [<ffffffffa003cf3a>] btrfs_finish_ordered_io+0x131/0xa4b [btrfs]
> [ 6865.184930] [<ffffffffa003d869>] finish_ordered_fn+0x15/0x17 [btrfs]
> [ 6865.184951] [<ffffffffa005882f>] worker_loop+0x145/0x516 [btrfs]
> [ 6865.184959] [<ffffffff81059727>] ? __wake_up_common+0x54/0x84
> [ 6865.184983] [<ffffffffa00586ea>] ? btrfs_queue_worker+0x2d3/0x2d3 [btrfs]
> [ 6865.184989] [<ffffffff810516bb>] kthread+0x93/0x98
> [ 6865.184996] [<ffffffff817d7934>] kernel_thread_helper+0x4/0x10
> [ 6865.185001] [<ffffffff81051628>] ? kthread_freezable_should_stop+0x6a/0x6a
> [ 6865.185021] [<ffffffff817d7930>] ? gs_change+0xb/0xb
> [ 6865.185025] ---[ end trace 26cc0e186efc79d8 ]---
>
>
> I'm testing a 3.5.4 kernel merged with 3.6_rc patchset as well as the
> send_recv patches and most of the btrfs-next patches.
>
> I'm running into this issue when mounting with autodefrag, and running
> some snapshot tests.
>
> This may be related to a problem elsewhere, because I've been
> encountering other backref issues even before testing this patch.
>
Oh, will look into it, thanks for the report.
thanks,
liubo
next prev parent reply other threads:[~2012-09-26 1:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 9:58 [PATCH 1/2 v3] Btrfs: use flag EXTENT_DEFRAG for snapshot-aware defrag Liu Bo
2012-09-17 9:58 ` [PATCH 2/2 v3] Btrfs: " Liu Bo
2012-09-17 10:04 ` Liu Bo
2012-09-17 17:15 ` Josef Bacik
2012-09-18 0:23 ` Liu Bo
2012-09-18 13:10 ` Josef Bacik
2012-09-25 17:39 ` Mitch Harder
2012-09-26 1:07 ` Liu Bo [this message]
2012-10-03 14:02 ` Chris Mason
2012-10-04 14:22 ` Liu Bo
2012-10-04 19:40 ` Mitch Harder
2012-10-08 12:18 ` Liu Bo
2012-10-08 13:19 ` Chris Mason
2012-10-08 15:06 ` Mitch Harder
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=50625569.9040102@oracle.com \
--to=bo.li.liu@oracle.com \
--cc=dave@jikos.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=mitch.harder@sabayonlinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).