diff mbox

[1/2] Btrfs: fix btrfs_is_free_space_inode to recognize btree inode

Message ID 1341919719-13825-1-git-send-email-liubo2009@cn.fujitsu.com (mailing list archive)
State New, archived
Headers show

Commit Message

liubo July 10, 2012, 11:28 a.m. UTC
For btree inode, its root is also 'tree root', so btree inode can be
misunderstood as a free space inode.

We should add one more check for btree inode.

Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
---
 fs/btrfs/btrfs_inode.h |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

Comments

Alex Lyakas July 18, 2012, 10:02 a.m. UTC | #1
Hi Liu,
can you pls explain this a bit more to me.
I see in my fs that there are (FREE_SPACE,0, offset) items in the root
tree. It seems that offset here is the objectid of the appropriate
BLOCK_GROUP_ITEM. Also, I see that each FREE_SPACE points at some
INODE_ITEM within the root tree, and this INODE_ITEM also has extents.
I presume that these extents contain the free space cache in some
format, is that correct?

However, I don't see any FREE_INO entries, what are they? Are they
perhaps used only when "inode_cache" mount option is used, so inode
numbers are not always incremented in btrfs_find_free_ino(), but
smaller unused numbers are reused?

Also, I don't see anywhere BTRFS_BTREE_INODE_OBJECTID in the tree root
tree. So what is this "btree inode" that you mention?

Thanks,
Alex.


On Tue, Jul 10, 2012 at 2:28 PM, Liu Bo <liubo2009@cn.fujitsu.com> wrote:
> For btree inode, its root is also 'tree root', so btree inode can be
> misunderstood as a free space inode.
>
> We should add one more check for btree inode.
>
> Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
> ---
>  fs/btrfs/btrfs_inode.h |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
> index 12394a9..b168238 100644
> --- a/fs/btrfs/btrfs_inode.h
> +++ b/fs/btrfs/btrfs_inode.h
> @@ -194,8 +194,10 @@ static inline void btrfs_i_size_write(struct inode *inode, u64 size)
>  static inline bool btrfs_is_free_space_inode(struct btrfs_root *root,
>                                        struct inode *inode)
>  {
> -       if (root == root->fs_info->tree_root ||
> -           BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
> +       if (root == root->fs_info->tree_root &&
> +           btrfs_ino(inode) != BTRFS_BTREE_INODE_OBJECTID)
> +               return true;
> +       if (BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
>                 return true;
>         return false;
>  }
> --
> 1.6.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
liubo July 18, 2012, 12:02 p.m. UTC | #2
On 07/18/2012 06:02 PM, Alex Lyakas wrote:

> Hi Liu,
> can you pls explain this a bit more to me.
> I see in my fs that there are (FREE_SPACE,0, offset) items in the root
> tree. It seems that offset here is the objectid of the appropriate
> BLOCK_GROUP_ITEM. Also, I see that each FREE_SPACE points at some
> INODE_ITEM within the root tree, and this INODE_ITEM also has extents.
> I presume that these extents contain the free space cache in some
> format, is that correct?
> 


More or less.

As its name shows, a free space inode's data (you name it extents) consists of
free space info, meanwhile, a free space inode is issued to a block group,
so the free space info actually stands for free space in the block group:

|<-    a block group len    ->|
|----vvv----vvv-------vvv-----|

'v' : occupied.
'-' : available. (free space)

these free space info are indexed in a rbtree in memory, and each entry has [start, len].


> However, I don't see any FREE_INO entries, what are they? Are they
> perhaps used only when "inode_cache" mount option is used, so inode
> numbers are not always incremented in btrfs_find_free_ino(), but
> smaller unused numbers are reused?
> 


Yes, that's what it is used for.

> Also, I don't see anywhere BTRFS_BTREE_INODE_OBJECTID in the tree root
> tree. So what is this "btree inode" that you mention?
> 


The code refers to disk_io.c, in the function 'open_ctree()' you can see the definition.

Basically btree inode's data stands for btrfs's metadata, I think you can find something
in btrfs's wiki page?


And thanks for your energy on btrfs! :)

thanks,
liubo

> Thanks,
> Alex.
> 
> 
> On Tue, Jul 10, 2012 at 2:28 PM, Liu Bo <liubo2009@cn.fujitsu.com> wrote:
>> For btree inode, its root is also 'tree root', so btree inode can be
>> misunderstood as a free space inode.
>>
>> We should add one more check for btree inode.
>>
>> Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
>> ---
>>  fs/btrfs/btrfs_inode.h |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
>> index 12394a9..b168238 100644
>> --- a/fs/btrfs/btrfs_inode.h
>> +++ b/fs/btrfs/btrfs_inode.h
>> @@ -194,8 +194,10 @@ static inline void btrfs_i_size_write(struct inode *inode, u64 size)
>>  static inline bool btrfs_is_free_space_inode(struct btrfs_root *root,
>>                                        struct inode *inode)
>>  {
>> -       if (root == root->fs_info->tree_root ||
>> -           BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
>> +       if (root == root->fs_info->tree_root &&
>> +           btrfs_ino(inode) != BTRFS_BTREE_INODE_OBJECTID)
>> +               return true;
>> +       if (BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
>>                 return true;
>>         return false;
>>  }
>> --
>> 1.6.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alex Lyakas July 18, 2012, 12:39 p.m. UTC | #3
On Wed, Jul 18, 2012 at 3:02 PM, Liu Bo <liubo2009@cn.fujitsu.com> wrote:
> On 07/18/2012 06:02 PM, Alex Lyakas wrote:
>
> More or less.
>
> As its name shows, a free space inode's data (you name it extents) consists of
> free space info, meanwhile, a free space inode is issued to a block group,
> so the free space info actually stands for free space in the block group:
>
> |<-    a block group len    ->|
> |----vvv----vvv-------vvv-----|
>
> 'v' : occupied.
> '-' : available. (free space)
>
> these free space info are indexed in a rbtree in memory, and each entry has [start, len].

Thanks, it makes sense with what I saw in the code, just could not
figure how this free-space inode's data is being read into memory.

>
>> Also, I don't see anywhere BTRFS_BTREE_INODE_OBJECTID in the tree root
>> tree. So what is this "btree inode" that you mention?
>>
>
>
> The code refers to disk_io.c, in the function 'open_ctree()' you can see the definition.
>

I saw it there, but not on disk. So now I see that it's kind of a
special "top" inode, used for ... something, and this inode is not
stored anywhere on-disk.

Thanks, now I understand your patch. Also, I understand now that
FREE_INO items sit in the subvolume file tree (and perhaps also in the
root tree), because they need to track free inos for distinct ino
spaces.

> Basically btree inode's data stands for btrfs's metadata, I think you can find something
> in btrfs's wiki page?

>
>
> And thanks for your energy on btrfs! :)

Thanks for helping.

Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 12394a9..b168238 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -194,8 +194,10 @@  static inline void btrfs_i_size_write(struct inode *inode, u64 size)
 static inline bool btrfs_is_free_space_inode(struct btrfs_root *root,
 				       struct inode *inode)
 {
-	if (root == root->fs_info->tree_root ||
-	    BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
+	if (root == root->fs_info->tree_root &&
+	    btrfs_ino(inode) != BTRFS_BTREE_INODE_OBJECTID)
+		return true;
+	if (BTRFS_I(inode)->location.objectid == BTRFS_FREE_INO_OBJECTID)
 		return true;
 	return false;
 }