Okay, that makes lot more sense to me now. Thank you very much.
Regards, Aastha. On 5 March 2013 02:51, Josef Bacik <jo...@toxicpanda.com> wrote: > On Mon, Mar 4, 2013 at 7:57 PM, Aastha Mehta <aasth...@gmail.com> wrote: >> I must admit, it is quite convoluted :-) >> >> Please tell me if I understand this. A file system tree (containing >> the inodes, the extents of all the inodes, etc.) is itself laid out in >> the leaf extents of another big tree, which is the root tree. This is >> why you say that inode and other such metadata may be lying in the >> leaf nodes. Correct? >> > > Sort of. We have lot's of tree's, but the inode data is laid out in > what we refer to as fs trees. All these trees are just b-trees that > have different data in them. In the fs-trees they will hold inode > items, directory items, file extent items, xattr items and orphan > items. So any given leaf in this tree could have any number of those > items in them referring to any number of inodes. You could have > > [inode item for inode 1][file extent item for inode 1][inode item for > inode 2][xattr for inode 2][file extent item for inode 2] > > all contained within one leaf. Does that make sense? > >> I did not completely understand what you meant when you said that the >> metadata (the file extent items and such) for the inodes are stored >> inside the same tree that the inode resides in. I thought the >> btrfs_file_extent_item associated with EXTENT_DATA_KEY corresponds to >> the actual data of a file. >> > > Yes the btrfs_file_extent_item points to a [offset, size] pair that > describes a data extent. > >> Okay, now I am not even sure if in btrfs there is something like an >> indirect block for a huge file. In file systems with fixed block size, >> one can hold only as many pointers to data blocks and hence when the >> file size grows indirects are added in the file's tree. Is there any >> equivalent indirect extent required for huge files in btrfs, or do all >> the files fit within one level? If there are indirects, what item type >> do they have? Would something like btrfs_get_extent() be useful to get >> the indirect extents of a file? >> > > So there are no indirects, there are just btrfs_file_extent_items that > are held within the btree that describe all of the extents that relate > to a particular file. So you can have (in the case of large > fragmented files) hundreds of leaves within the btree that just > contain btrfs_file_extent_items for all the ranges for a file. > btrfs_get_extent() just looks up the relevant btrfs_file_extent_item > for the range that you are wondering about, and maps it to our > extent_map structure internally. Hth, > > Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
