linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: Omar Sandoval <osandov@osandov.com>, <linux-btrfs@vger.kernel.org>
Cc: Omar Sandoval <osandov@fb.com>
Subject: Re: [PATCH 5/6] Btrfs: wire up the free space tree to the extent tree
Date: Tue, 1 Sep 2015 15:48:57 -0400	[thread overview]
Message-ID: <55E60129.3070009@fb.com> (raw)
In-Reply-To: <5354d2ad80625f36be4032664a7d39f4c4874119.1441131625.git.osandov@fb.com>

On 09/01/2015 03:05 PM, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> The free space tree is updated in tandem with the extent tree. There are
> only a handful of places where we need to hook in:
>
> 1. Block group creation
> 2. Block group deletion
> 3. Delayed refs (extent creation and deletion)
> 4. Block group caching
>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
>   fs/btrfs/extent-tree.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++---
>   1 file changed, 70 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 37179a569f40..3f10df3932f0 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -33,6 +33,7 @@
>   #include "raid56.h"
>   #include "locking.h"
>   #include "free-space-cache.h"
> +#include "free-space-tree.h"
>   #include "math.h"
>   #include "sysfs.h"
>   #include "qgroup.h"
> @@ -589,7 +590,41 @@ static int cache_block_group(struct btrfs_block_group_cache *cache,
>   	cache->cached = BTRFS_CACHE_FAST;
>   	spin_unlock(&cache->lock);
>
> -	if (fs_info->mount_opt & BTRFS_MOUNT_SPACE_CACHE) {
> +	if (btrfs_fs_compat_ro(fs_info, FREE_SPACE_TREE)) {
> +		if (load_cache_only) {
> +			spin_lock(&cache->lock);
> +			cache->caching_ctl = NULL;
> +			cache->cached = BTRFS_CACHE_NO;
> +			spin_unlock(&cache->lock);
> +			wake_up(&caching_ctl->wait);
> +		} else {
> +			mutex_lock(&caching_ctl->mutex);
> +			ret = load_free_space_tree(fs_info, cache);
> +			if (ret) {
> +				btrfs_warn(fs_info, "failed to load free space tree for %llu: %d",
> +					   cache->key.objectid, ret);
> +				spin_lock(&cache->lock);
> +				cache->caching_ctl = NULL;
> +				cache->cached = BTRFS_CACHE_ERROR;
> +				spin_unlock(&cache->lock);
> +				goto tree_out;
> +			}
> +
> +			spin_lock(&cache->lock);
> +			cache->caching_ctl = NULL;
> +			cache->cached = BTRFS_CACHE_FINISHED;
> +			cache->last_byte_to_unpin = (u64)-1;
> +			caching_ctl->progress = (u64)-1;
> +			spin_unlock(&cache->lock);
> +			mutex_unlock(&caching_ctl->mutex);
> +
> +tree_out:
> +			wake_up(&caching_ctl->wait);
> +			put_caching_control(caching_ctl);
> +			free_excluded_extents(fs_info->extent_root, cache);
> +			return 0;
> +		}
> +	} else if (fs_info->mount_opt & BTRFS_MOUNT_SPACE_CACHE) {
>   		mutex_lock(&caching_ctl->mutex);

So the reason we have this load_cache_only thing is because the free 
space cache could be loaded almost instantaneously since it was 
contiguously allocated.  This isn't the case with the free space tree, 
and although it is better than the no space cache way of doing things, 
we are still going to incur a bit of latency when seeking through a 
large free space tree.  So break this out and make the caching kthread 
either do the old style load or load the free space tree.  Then you can 
use the add free space helpers that will wake anybody up waiting on 
allocations and you incur less direct latency.  Thanks,

Josef


  reply	other threads:[~2015-09-01 19:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 19:01 [PATCH 0/6] free space B-tree Omar Sandoval
2015-09-01 19:01 ` [PATCH 1/6] Btrfs: add extent buffer bitmap operations Omar Sandoval
2015-09-01 19:25   ` Josef Bacik
2015-09-01 19:37     ` Omar Sandoval
2015-09-01 19:01 ` [PATCH 2/6] Btrfs: add helpers for read-only compat bits Omar Sandoval
2015-09-01 19:26   ` Josef Bacik
2015-09-01 19:01 ` [PATCH 3/6] Btrfs: introduce the free space B-tree on-disk format Omar Sandoval
2015-09-01 19:28   ` Josef Bacik
2015-09-01 19:05 ` [PATCH 5/6] Btrfs: wire up the free space tree to the extent tree Omar Sandoval
2015-09-01 19:48   ` Josef Bacik [this message]
2015-09-02  4:42     ` Omar Sandoval
2015-09-02 15:29       ` Josef Bacik
2015-09-01 19:05 ` [PATCH 6/6] Btrfs: add free space tree mount option Omar Sandoval
2015-09-01 19:49   ` Josef Bacik
2015-09-01 19:13 ` [PATCH 4/6] Btrfs: implement the free space B-tree Omar Sandoval
2015-09-01 19:44   ` Josef Bacik
2015-09-01 20:06     ` Omar Sandoval
2015-09-01 20:08       ` Josef Bacik
2015-09-01 19:17 ` [PATCH 0/6] " Omar Sandoval
2015-09-01 19:22 ` [PATCH 1/3] btrfs-progs: use calloc instead of malloc+memset for tree roots Omar Sandoval
2015-09-01 19:22   ` [PATCH 2/3] btrfs-progs: add basic awareness of the free space tree Omar Sandoval
2015-09-01 19:22   ` [PATCH 3/3] btrfs-progs: check the free space tree in btrfsck Omar Sandoval
2015-09-02 15:02   ` [PATCH 1/3] btrfs-progs: use calloc instead of malloc+memset for tree roots David Sterba
2015-09-03 19:44 ` [PATCH v2 0/9] free space B-tree Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 1/9] Btrfs: add extent buffer bitmap operations Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 2/9] Btrfs: add extent buffer bitmap sanity tests Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 3/9] Btrfs: add helpers for read-only compat bits Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 4/9] Btrfs: refactor caching_thread() Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 5/9] Btrfs: introduce the free space B-tree on-disk format Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 6/9] Btrfs: implement the free space B-tree Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 7/9] Btrfs: add free space tree sanity tests Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 8/9] Btrfs: wire up the free space tree to the extent tree Omar Sandoval
2015-09-04  5:56     ` Omar Sandoval
2015-09-03 19:44   ` [PATCH v2 9/9] Btrfs: add free space tree mount option Omar Sandoval
2015-09-09 12:00     ` David Sterba
2015-09-11  0:52       ` Omar Sandoval
2015-09-04  1:29   ` [PATCH v2 0/9] free space B-tree Zhao Lei
2015-09-04  5:43     ` Omar Sandoval
2015-09-11  1:21   ` Qu Wenruo
2015-09-11  3:48     ` Omar Sandoval
2015-09-11  3:58       ` Qu Wenruo
2015-09-11  4:15         ` Omar Sandoval
2015-09-22 14:41     ` 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=55E60129.3070009@fb.com \
    --to=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=osandov@fb.com \
    --cc=osandov@osandov.com \
    /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).