All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.