From: Liu Bo <bo.li.liu@oracle.com>
To: Mitch Harder <mitch.harder@sabayonlinux.org>
Cc: linux-btrfs@vger.kernel.org, chris.mason@fusionio.com,
JBacik@fusionio.com, dave@jikos.cz, kitayama@cl.bb4u.ne.jp,
miaox@cn.fujitsu.com
Subject: Re: [PATCH V5] Btrfs: snapshot-aware defrag
Date: Thu, 24 Jan 2013 08:52:22 +0800 [thread overview]
Message-ID: <20130124005221.GA28406@liubo> (raw)
In-Reply-To: <CAKcLGm97CSThaz9u0sj8BE=bMGObc6rqCsmzf0AneWfhxfZFDw@mail.gmail.com>
On Wed, Jan 23, 2013 at 10:05:04AM -0600, Mitch Harder wrote:
> On Wed, Jan 23, 2013 at 1:51 AM, Liu Bo <bo.li.liu@oracle.com> wrote:
> > On Tue, Jan 22, 2013 at 11:41:19AM -0600, Mitch Harder wrote:
> >> On Thu, Jan 17, 2013 at 8:42 AM, Mitch Harder
> >> <mitch.harder@sabayonlinux.org> wrote:
> >> > On Wed, Jan 16, 2013 at 6:36 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.
> > [...]
> >> >
> >> > I've been testing this patch on a 3.7.2 kernel merged with the
> >> > for-linus branch for the 3.8_rc kernels, and I'm seeing the following
> >> > error:
> >> >
> >>
> >> I've reproduced the error with CONFIG_DEBUG_LIST enabled, which shows
> >> some problem with an entry in the list.
> >>
> >> [59312.260441] ------------[ cut here ]------------
> >> [59312.260454] WARNING: at lib/list_debug.c:62 __list_del_entry+0x8d/0x98()
> >> [59312.260458] Hardware name: OptiPlex 745
> >> [59312.260461] list_del corruption. next->prev should be
> >> ffff88006511c438, but was dead000000200200
> >
> > LIST_POISON2 -> (000000200200)
> > So we can know that the next one is deleted from the list even _earlier_
> > than the current one is.
> >
> > Any other messages before this warning complains?
> >
>
> Just some normal feedback from a metadata balance I had run.
Well, these do fit my expectation, since balance also involves with playing with
root_list, which may lead to the bad situation.
>
> [14057.193343] device fsid 28c688c5-7dbd-4071-b271-1bf6726d8835 devid
> 1 transid 4 /dev/sda7
> [14057.194438] btrfs: force lzo compression
> [14057.194446] btrfs: enabling auto defrag
> [14057.194449] btrfs: disk space caching is enabled
> [14057.194452] btrfs flagging fs with big metadata feature
> [14057.194455] btrfs: lzo incompat flag set.
> [57508.799193] btrfs: relocating block group 14516486144 flags 4
> [57632.178797] btrfs: found 6775 extents
> [57633.214701] btrfs: relocating block group 11832131584 flags 4
> [57776.400102] btrfs: found 6480 extents
> [57777.021175] btrfs: relocating block group 10489954304 flags 4
> [57949.182725] btrfs: found 6681 extents
> [59312.260441] ------------[ cut here ]------------
> [59312.260454] WARNING: at lib/list_debug.c:62 __list_del_entry+0x8d/0x98()
> [59312.260458] Hardware name: OptiPlex 745
> ...
>
> I'm going to try to wrap some debugging around the section of code in
> btrfs_clean_old_snapshots() where the dead_roots list is spliced onto
> the root list being processed. The double entry may be slipping in
> here.
>
> 1764 spin_lock(&fs_info->trans_lock);
> 1765 list_splice_init(&fs_info->dead_roots, &list);
> 1766 spin_unlock(&fs_info->trans_lock);
hmm, I don't think there is anything wrong in this code. But you can
give it a shot anyway :)
thanks,
liubo
next prev parent reply other threads:[~2013-01-24 0:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 12:36 [PATCH V5] Btrfs: snapshot-aware defrag Liu Bo
2013-01-17 14:42 ` Mitch Harder
2013-01-18 0:53 ` Liu Bo
2013-01-18 5:23 ` Mitch Harder
2013-01-18 12:19 ` David Sterba
2013-01-18 22:01 ` Mitch Harder
2013-01-22 17:41 ` Mitch Harder
2013-01-23 7:51 ` Liu Bo
2013-01-23 16:05 ` Mitch Harder
2013-01-24 0:52 ` Liu Bo [this message]
2013-01-25 14:55 ` Mitch Harder
2013-01-25 15:40 ` Stefan Behrens
2013-01-27 13:19 ` Liu Bo
2013-01-28 16:55 ` Stefan Behrens
2013-02-16 6:47 ` Liu Bo
2013-02-18 16:53 ` Stefan Behrens
2013-02-19 4:29 ` Liu Bo
2013-02-19 17:53 ` Stefan Behrens
2013-01-25 15:42 ` Liu Bo
2013-01-25 18:16 ` Mitch Harder
2013-01-27 12:41 ` Liu Bo
2013-01-28 5:20 ` Mitch Harder
2013-01-28 6:54 ` Liu Bo
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=20130124005221.GA28406@liubo \
--to=bo.li.liu@oracle.com \
--cc=JBacik@fusionio.com \
--cc=chris.mason@fusionio.com \
--cc=dave@jikos.cz \
--cc=kitayama@cl.bb4u.ne.jp \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
--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).