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

[Alex Lyakas <alex.bolshoy.btrfs@gmail.com>]

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.