From: Liu Bo <bo.li.liu@oracle.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 1/3] Btrfs: avoid building inode cache repeatly
Date: Fri, 13 Dec 2013 17:16:21 +0800 [thread overview]
Message-ID: <1386926183-18325-2-git-send-email-bo.li.liu@oracle.com> (raw)
In-Reply-To: <1386926183-18325-1-git-send-email-bo.li.liu@oracle.com>
Inode cache is similar to free space cache and in fact shares the same
code, however, we don't load inode cache unless we're about to allocate
inode id, then there is a case where we only commit the transaction during
other operations, such as snapshot creation, we now update fs roots' generation
to the new transaction id, after that when we want to load the inode cache,
we'll find that it's not valid thanks to the mismatch of generation, and we
have to push btrfs-ino-cache thread to build inode cache from disk, and
this operation is sometimes time-costing.
So to fix the above, we load inode cache into memory during reading fs root.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
fs/btrfs/disk-io.c | 9 +++++----
fs/btrfs/inode-map.c | 2 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 8072cfa..cb0b12b 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1524,14 +1524,15 @@ int btrfs_init_fs_root(struct btrfs_root *root)
goto fail;
}
- btrfs_init_free_ino_ctl(root);
+ ret = get_anon_bdev(&root->anon_dev);
+ if (ret)
+ goto fail;
+
mutex_init(&root->fs_commit_mutex);
spin_lock_init(&root->cache_lock);
init_waitqueue_head(&root->cache_wait);
+ btrfs_init_free_ino_ctl(root);
- ret = get_anon_bdev(&root->anon_dev);
- if (ret)
- goto fail;
return 0;
fail:
kfree(root->free_ino_ctl);
diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c
index ab485e5..6c8d7bb 100644
--- a/fs/btrfs/inode-map.c
+++ b/fs/btrfs/inode-map.c
@@ -388,6 +388,8 @@ void btrfs_init_free_ino_ctl(struct btrfs_root *root)
pinned->private = NULL;
pinned->extents_thresh = 0;
pinned->op = &pinned_free_ino_op;
+
+ start_caching(root);
}
int btrfs_save_ino_cache(struct btrfs_root *root,
--
1.8.2.1
next prev parent reply other threads:[~2013-12-13 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 9:16 [PATCH 0/3] Btrfs: inode cache fixes Liu Bo
2013-12-13 9:16 ` Liu Bo [this message]
2013-12-13 9:38 ` [PATCH 1/3] Btrfs: avoid building inode cache repeatly Miao Xie
2013-12-13 9:16 ` [PATCH 2/3] Btrfs: don't build inode cache for orphan root Liu Bo
2013-12-13 9:43 ` Miao Xie
2013-12-13 9:16 ` [PATCH 3/3] Btrfs: fix EEXIST error when creating new file in subvolume/snapshot Liu Bo
2013-12-13 9:46 ` Miao Xie
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=1386926183-18325-2-git-send-email-bo.li.liu@oracle.com \
--to=bo.li.liu@oracle.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;
as well as URLs for NNTP newsgroup(s).