On Wed, Jul 18, 2012 at 3:02 PM, Liu Bo <liubo2009@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
