dba785a9db
Add new directory and move ther all exisisting documentation meant for developers. Signed-off-by: David Sterba <dsterba@suse.com>
112 lines
4 KiB
ReStructuredText
112 lines
4 KiB
ReStructuredText
Btrees
|
||
======
|
||
|
||
Btrees Introduction
|
||
-------------------
|
||
|
||
Btrfs uses a single set of btree manipulation code for all metadata in
|
||
the filesystem. For performance or organizational purposes, the trees
|
||
are broken up into a few different types, and each type of tree will
|
||
hold a few different types of keys. The super block holds pointers to
|
||
the tree roots of the tree of tree roots and the chunk tree.
|
||
|
||
|
||
Tree of Tree roots
|
||
------------------
|
||
|
||
This tree is used for indexing and finding the root of most of the other
|
||
trees in the filesystem. It attaches names to subvolumes and snapshots,
|
||
and stores the location of the extent allocation tree root. It also
|
||
stores pointers to all of the subvolumes or snapshots that are being
|
||
deleted by the transaction code. This allows the deletion to pick up
|
||
where it left off after a crash.
|
||
|
||
|
||
Chunk Tree
|
||
----------
|
||
|
||
The chunk tree does all of the logical to physical block address mapping
|
||
for the filesystem, and it stores information about all of the devices
|
||
in the FS. In order to bootstrap lookup in the chunk tree, the super
|
||
block also duplicates the chunk items needed to resolve blocks in the
|
||
chunk tree. Over time, the chunk tree will be split into multiple roots
|
||
to allow access of larger storage pools.
|
||
|
||
There are back references from the chunk items to the extent tree that
|
||
allocated them. Only a single extent tree can allocate extents out of a
|
||
given chunk.
|
||
|
||
Two types of key are stored in the chunk tree:
|
||
|
||
- DEV_ITEM (where the offset field is the internal devid), which
|
||
contain information on all of the underlying block devices in the
|
||
filesystem
|
||
- CHUNK_ITEM (where the offset field is the start of the chunk as a
|
||
virtual address), which maps a section of the virtual address space
|
||
(a chunk) into physical storage.
|
||
|
||
|
||
Device Allocation Tree
|
||
----------------------
|
||
|
||
The device allocation tree records which parts of each physical device
|
||
have been allocated into chunks. This is a relatively small tree that is
|
||
only updated as new chunks are allocated. It stores back references to
|
||
the chunk tree that allocated each physical extent on the device.
|
||
|
||
|
||
Extent Allocation Tree
|
||
----------------------
|
||
|
||
The extent allocation tree records byte ranges that are in use,
|
||
maintains reference counts on each extent and records back references to
|
||
the tree or file that is using each extent. Logical block groups are
|
||
created inside the extent allocation tree, and these reference large
|
||
logical extents from the chunk tree.
|
||
|
||
Each block group can only store a specific type of extent. This might
|
||
include metadata, or mirrored metadata, or striped data blocks etc.
|
||
|
||
Currently there is only one extent allocation tree shared by all the
|
||
other trees. This will change in order to scale better under load.
|
||
|
||
Keys for the extent tree use the start of the extent as the objectid. A BLOCK_GROUP_ITEM key will be followed by the EXTENT_ITEM keys for extents within that block group.
|
||
|
||
|
||
FS Trees
|
||
--------
|
||
|
||
These store files and directories, and all of the normal metadata you
|
||
would expect to find in a filesystem. There is one root for each
|
||
subvolume or snapshot, but snapshots will share blocks between roots.
|
||
|
||
Keys in FS trees always use the inode number of the filesystem object as the objectid.
|
||
|
||
Each object will have one or more of:
|
||
|
||
- Inode.
|
||
- Inode ref, indicating what name this object is known as, and in which
|
||
directory.
|
||
- For files, a set of extent information, indicating where on the
|
||
filesystem this file's data is.
|
||
- For directories, two sequences of dir_items, one indexed by a hash of
|
||
the object name, and one indexed by a unique sequential index number.
|
||
|
||
|
||
Checksum Tree
|
||
-------------
|
||
|
||
The checksum tree stores block checksums. Every 4k block of data stored
|
||
on disk has a checksum associated with it. The "offset" part of the keys
|
||
in the checksum tree indicates the start of the checksummed data on
|
||
disk. The value stored with the key is a sequence of (currently 4-byte)
|
||
checksums, for the 4k blocks starting at the offset.
|
||
|
||
|
||
Data Relocation Tree
|
||
--------------------
|
||
|
||
|
||
Log Root Tree
|
||
-------------
|