Store those things. (v) Detailed btree structure of btrfs file system

Btree data structure can be said to be the basis of Btrfs file system. It provides a common way to store different data types. It stores only 3 data types: Key, item, and block header.

The definition of Btrfs_header is as follows:

struct Btrfs_header {    
    U8 csum[32];    
    U8 fsid[16];    
    __le64 BLOCKNR;    
    __LE64 flags;    
        
    U8 chunk_tree_uid[16];    
    __le64 generation;    
    __le64 owner;    
    __le32 Nritems;    
    U8 level;    

The definition of Btrfs_disk_key is as follows:

struct Btrfs_disk_key {    
    __le64 objectid;    
    U8 type;    
    __le64 offset;    
}

The definition of Btrfs_item is as follows:

struct Btrfs_item {    
    struct btrfs_disk_key key;    
    __le32 offset;    
    __le32 size;    
}

For B-tree nodes, it only holds [Key, Block-pointer]. The leaf node holds [item, data]. The size of the data is not fixed. The leaf saves an array of items at the beginning. At the end, an array of data is saved in the opposite direction. The two arrays are growing toward the middle. The structure body btrfs_item.offset the offset of the data, while Btrfs_item.size saves the size of the data. The following figure illustrates this problem:

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/storage/

The item's data size is not fixed. And for different data structures, the type of this is not the same. Struct Btrfs_disk_key::type describes the different categories of data.

Btrfs_header saves a checksum of this node's data, the ID of the file system of the node, the level of the node in the tree, the number of blocks the node occupies. These member data can validate the metadata while reading the data. For the owner pointing to the Btree node, it stores the value of the generation, which guarantees the correctness of the metadata.

For a node pointer to a lower node, the checksum of the underlying node is not saved in order to simplify the logic of file writeback. Generation is calculated when the node is inserted into the btree, but checksum is only computed when the block is written back to disk. Therefore, using generation will cause Btrfs to detect incorrect writeback. If you use checksum, then because the checksum of the lower nodes will only be computed when it is written to disk, it is very inefficient to have to modify the checksum of the upper level to point to that node after the calculation gets checksum.

So how did the generation figure out? is to assign the transaction ID of the current node. This also makes incremental backups easier. Of course, this transaction ID is used by the cow transaction subsystem.

For struct Btrfs_key.objectid, it uniquely identifies the logical unit, or object. Btrfs is composed of these objects. When object is created, an object ID that is not used by other object is assigned to it. Objectid can be said to be the most important element in key. By Objectid, all of the object can be organized into b-tree.

Inode

The inode is present in the struct Btrfs_inode_item, where Key.offset = 0 and Key.Type = = 1. The item of the Inode is certainly the first, and they hold the state information of the traditional files and directories. It is relatively small and does not contain embedded file data or extended attributes. This information is saved to other types of item.

File

A small file may be placed on an extended item if it can be placed on a leaf node. In this case, Key.offset saves the offset in the extent of the file data, and the size of the file is saved in Btrfs_item.size. This file becomes inline file, which is very fast because it reduces addressing and IO.

For large files, they are stored in extent. Struct_file_extent_item stores the generation number of this extent and a [disk block, disk num blocks] pair to record where the file is stored.

SOURCE anzhsoft:http://blog.csdn.net/anzhsoft/article/details/20382885