All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: dsterba@suse.cz, Jeff Mahoney <jeffm@suse.com>,
	Filipe Manana <fdmanana@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 1/2] btrfs-progs: check: run delayed refs after writing out dirty block groups
Date: Wed, 15 May 2019 15:45:13 +0100	[thread overview]
Message-ID: <CAL3q7H45c8H91vbz=9yPmtPE95Ret1XLNW3kNT5XGs6L2-GAAw@mail.gmail.com> (raw)
In-Reply-To: <20190515141605.GQ3138@twin.jikos.cz>

On Wed, May 15, 2019 at 3:15 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Wed, Apr 03, 2019 at 10:38:09PM -0400, Jeff Mahoney wrote:
> > On 4/2/19 3:19 PM, Filipe Manana wrote:
> > > On Tue, Apr 2, 2019 at 7:29 PM <jeffm@suse.com> wrote:
> > >>
> > >> From: Jeff Mahoney <jeffm@suse.com>
> > >>
> > >> When repairing the extent tree, it's possible for delayed extents to
> > >> be created when running btrfs_write_dirty_block_groups.  We run
> > >> delayed refs one last time in the kernel but that is missing in
> > >> the userspace tools.
> > >>
> > >> That results in delayed refs getting dropped on the floor, the extent
> > >> records not getting created, and in the next tranaction, when the
> > >> extent tree is CoW'd again, we hit the BUG_ON when we can't find
> > >> the extent record.
> > >>
> > >> We can fix this by running the delayed refs after writing out the
> > >> dirty block groups.
> > >>
> > >> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> > >> ---
> > >>  transaction.c | 2 ++
> > >>  1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/transaction.c b/transaction.c
> > >> index e756db33..2f19e9c8 100644
> > >> --- a/transaction.c
> > >> +++ b/transaction.c
> > >> @@ -194,6 +194,8 @@ commit_tree:
> > >>         ret = btrfs_run_delayed_refs(trans, -1);
> > >>         BUG_ON(ret);
> > >>         btrfs_write_dirty_block_groups(trans);
> > >> +       ret = btrfs_run_delayed_refs(trans, -1);
> > >> +       BUG_ON(ret);
> > >
> > > And running delayed refs can dirty more block groups as well.
> > > At this point shouldn't we loop running delayed refs until no more
> > > dirty block groups exist? Just like in the kernel.
> >
> > Right.  This is another argument for code sharing between the kernel and
> > userspace.
>
> Sharing code in this function would be really hard, I've implemented the
> loop in commit in progs.

Shouldn't the new patch version be sent to the list for review?
It doesn't seem to be a trivial change on first through.

Thanks.



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

  reply	other threads:[~2019-05-15 14:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 18:09 [PATCH 1/2] btrfs-progs: check: run delayed refs after writing out dirty block groups jeffm
2019-04-02 18:09 ` [PATCH 2/2] btrfs-progs: check: fixup_extent_flags needs to deal with non-skinny metadata jeffm
2019-04-02 19:21   ` Filipe Manana
2019-04-02 19:19 ` [PATCH 1/2] btrfs-progs: check: run delayed refs after writing out dirty block groups Filipe Manana
2019-04-04  2:38   ` Jeff Mahoney
2019-05-15 14:16     ` David Sterba
2019-05-15 14:45       ` Filipe Manana [this message]
2019-05-17 13:12         ` David Sterba
2019-07-24 13:53           ` Jeff Mahoney
2019-07-24 14:17             ` David Sterba

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='CAL3q7H45c8H91vbz=9yPmtPE95Ret1XLNW3kNT5XGs6L2-GAAw@mail.gmail.com' \
    --to=fdmanana@gmail.com \
    --cc=dsterba@suse.cz \
    --cc=jeffm@suse.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.