From: Miao Xie <miaox@cn.fujitsu.com>
To: bo.li.liu@oracle.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/3] Btrfs: avoid building inode cache repeatly
Date: Mon, 16 Dec 2013 18:54:02 +0800 [thread overview]
Message-ID: <52AEDBCA.2090904@cn.fujitsu.com> (raw)
In-Reply-To: <20131216102601.GC30413@localhost.localdomain>
On Mon, 16 Dec 2013 18:26:02 +0800, Liu Bo wrote:
> On Mon, Dec 16, 2013 at 05:04:33PM +0800, Miao Xie wrote:
>> On mon, 16 Dec 2013 15:25:33 +0800, Liu Bo wrote:
>>> 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>
>>> ---
>>> v2: fix race issue pointed by Miao.
>>>
>>> fs/btrfs/disk-io.c | 3 +++
>>> fs/btrfs/inode-map.c | 6 ++++++
>>> fs/btrfs/inode-map.h | 1 +
>>> fs/btrfs/root-tree.c | 3 +++
>>> 4 files changed, 13 insertions(+)
>>>
>>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>>> index 8072cfa..59af2aa 100644
>>> --- a/fs/btrfs/disk-io.c
>>> +++ b/fs/btrfs/disk-io.c
>>> @@ -1630,6 +1630,9 @@ again:
>>> }
>>> goto fail;
>>> }
>>> +
>>> + btrfs_start_ino_caching(root);
>>> +
>>> return root;
>>> fail:
>>> free_fs_root(root);
>>> diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c
>>> index ab485e5..f23b0df 100644
>>> --- a/fs/btrfs/inode-map.c
>>> +++ b/fs/btrfs/inode-map.c
>>> @@ -179,6 +179,12 @@ static void start_caching(struct btrfs_root *root)
>>> BUG_ON(IS_ERR(tsk)); /* -ENOMEM */
>>> }
>>>
>>> +void btrfs_start_ino_caching(struct btrfs_root *root)
>>> +{
>>> + if (root)
>>> + start_caching(root);
>>> +}
>>
>> We are sure root is not NULL, so this check is unnecessary.
>>
>> I dipped into the problem, I don't think loading inode cache during reading
>> fs root is a good way to fix this problem, because in some cases, we read
>> the fs/file root, but we don't want to allocate/free the inode id.
>>
>> I think we can add a flag, which is used to mark if the fs/file root has inode
>> id cache. We can set the flag when we reading the fs/file root. If the flag is
>> set but we don't allocate/free the inode id from/to the inode id cache, we set
>> the generation in the space cache header to 0, which can avoid loading a invalid
>> inode cache, and then clear the flag. How about this idea?
>
> That's same with the current code.
One important point I forgot is that use the generation in the space cache header to
check the cache inode generation, don't use the root generation,
> If we don't allocate/free inode ids, @root->cached remains BTRFS_CACHE_NO, and
> btrfs_save_ino_cache will set inode cache's generation to 0.
>
> So the problem of rebuilding inode cache repeatly is not loading an invalid
> ino-cache.
>
> btrfs_save_ino_cache() cleanup a valid inode cache during transaction commit
> because of options INODE_MAP, and find that inode cache is not even loaded
> during that committed transaction, and it just skip writing out inode cache.
> Next time when we're allocating inode ids, we load the inode cache and find it
> is there but already outdated so that we have to rebuild another one same with
> the previous cache.
>
> To fit what you concerned, btrfs_save_ino_cache() reminds us that only fs tree
> and subvol/snap need ino cache, so I think adding a check like that is enough
> to filter out those fs/file roots where we don't want to allocate/free inode
> ids, eg. data reloc root.
use a flag to indicate if the ino cache is dirty, just like free space cache.
If not dirty, skip the save process.
Thanks
Miao
next prev parent reply other threads:[~2013-12-16 10:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 7:25 [PATCH v2 0/3] Btrfs: inode cache fixes Liu Bo
2013-12-16 7:25 ` [PATCH v2 1/3] Btrfs: avoid building inode cache repeatly Liu Bo
2013-12-16 9:04 ` Miao Xie
2013-12-16 10:26 ` Liu Bo
2013-12-16 10:54 ` Miao Xie [this message]
2013-12-16 15:09 ` Chris Mason
2013-12-16 7:25 ` [PATCH v2 2/3] Btrfs: don't build inode cache for orphan root Liu Bo
2013-12-16 7:25 ` [PATCH v2 3/3] Btrfs: fix EEXIST error when creating new file in subvolume/snapshot Liu Bo
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=52AEDBCA.2090904@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=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).