Re: [PATCH 1/2] btrfs-progs: check: run delayed refs after writing out dirty block groups

[Filipe Manana <fdmanana@gmail.com>]

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.

thanks

>         __commit_transaction(trans, root);
>         if (ret < 0)
>                 goto out;
> --
> 2.16.4
>


-- 
Filipe David Manana,

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