public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Boris Burkov <boris@bur.io>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v3 3/4] btrfs: remove free space items when creating free space tree
Date: Mon, 21 Sep 2020 19:13:04 +0200	[thread overview]
Message-ID: <20200921171304.GM6756@twin.jikos.cz> (raw)
In-Reply-To: <e8c4e0e500f1f19787c84cf8fb7a54063f0fedf0.1600282812.git.boris@bur.io>

On Thu, Sep 17, 2020 at 11:13:40AM -0700, Boris Burkov wrote:
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -3333,6 +3333,15 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
>  			close_ctree(fs_info);
>  			return ret;
>  		}
> +		/*
> +		 * Creating the free space tree creates inode orphan items and
> +		 * delayed iputs when it deletes the free space inodes. Later in
> +		 * open_ctree, we run btrfs_orphan_cleanup which tries to clean
> +		 * up the orphan items. However, the outstanding references on
> +		 * the inodes from the delayed iputs causes the cleanup to fail.
> +		 * To fix it, force going through the delayed iputs here.
> +		 */
> +		btrfs_run_delayed_iputs(fs_info);

This is called from open_ctree, so this is mount context and the free
space tree creation is called before that. That will schedule all free
space inodes for deletion and waits here. This takes time proportional
to the filesystem size.

We've had reports that this takes a lot of time already, so I wonder if
the delayed iputs can be avoided here.

  parent reply	other threads:[~2020-09-21 17:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 18:13 [PATCH v3 0/4] btrfs: free space tree mounting fixes Boris Burkov
2020-09-17 18:13 ` [PATCH v3 1/4] btrfs: support remount of ro fs with free space tree Boris Burkov
2020-09-21 14:35   ` Josef Bacik
2020-09-24 17:02   ` David Sterba
2020-09-17 18:13 ` [PATCH 2/4] btrfs: use sb state to print space_cache mount option Boris Burkov
2020-09-21 14:50   ` Josef Bacik
2020-09-21 17:04     ` David Sterba
2020-09-21 17:13       ` Boris Burkov
2020-09-24 17:04   ` David Sterba
2020-09-17 18:13 ` [PATCH v3 3/4] btrfs: remove free space items when creating free space tree Boris Burkov
2020-09-21 14:54   ` Josef Bacik
2020-09-21 17:13   ` David Sterba [this message]
2020-09-21 18:22     ` Boris Burkov
2020-09-21 19:01     ` Josef Bacik
2020-09-24 17:07   ` David Sterba
2020-09-17 18:13 ` [PATCH 4/4] btrfs: skip space_cache v1 setup when not using it Boris Burkov
2020-09-21 14:54   ` Josef Bacik
2020-09-18 14:23 ` [PATCH v3 0/4] btrfs: free space tree mounting fixes 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=20200921171304.GM6756@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=boris@bur.io \
    --cc=kernel-team@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox