Status
m (→Overview) |
(→Overview: 4.12: raid56 auto repair) |
||
| (2 intermediate revisions by one user not shown) | |||
| Line 8: | Line 8: | ||
While a feature may be functionally safe and reliable, it does not necessarily mean that its useful, for example in meeting your performance expectations for your specific workload. | While a feature may be functionally safe and reliable, it does not necessarily mean that its useful, for example in meeting your performance expectations for your specific workload. | ||
| − | The table is based on the latest released linux kernel | + | The table is based on the latest released linux kernel: '''4.12''' |
{| class="wikitable" border=1 | {| class="wikitable" border=1 | ||
| Line 51: | Line 51: | ||
|- | |- | ||
| Scrub + RAID56 | | Scrub + RAID56 | ||
| − | | style="background: | + | | style="background: orange;" | mostly OK |
| − | + | ||
|- | |- | ||
| nodatacow | | nodatacow | ||
| Line 168: | Line 167: | ||
* btrfs-progs versions before v4.7.3 might accidentally do writes to the filesystem, but since there's no way to invalidate the FST, this causes inconsistency and possible corruption (using a piece of space twice). ''If'' you have made changes (btrfstune, repair, ...) to a FST enabled filesystem with btrfs progs, then mount with clear_cache,space_cache=v2 and hope the space written to was not reused yet. (see [https://www.spinics.net/lists/linux-btrfs/msg59110.html Status of free-space-tree feature]) | * btrfs-progs versions before v4.7.3 might accidentally do writes to the filesystem, but since there's no way to invalidate the FST, this causes inconsistency and possible corruption (using a piece of space twice). ''If'' you have made changes (btrfstune, repair, ...) to a FST enabled filesystem with btrfs progs, then mount with clear_cache,space_cache=v2 and hope the space written to was not reused yet. (see [https://www.spinics.net/lists/linux-btrfs/msg59110.html Status of free-space-tree feature]) | ||
* (fixed in linux 4.9) runtime support: fine on little-endian machines (x86*), known to be broken on big-endian (sparc64), see [https://bugzilla.kernel.org/show_bug.cgi?id=152111 sparc64: btrfs module fails to load on big-endian machines] | * (fixed in linux 4.9) runtime support: fine on little-endian machines (x86*), known to be broken on big-endian (sparc64), see [https://bugzilla.kernel.org/show_bug.cgi?id=152111 sparc64: btrfs module fails to load on big-endian machines] | ||
| + | |||
| + | === RAID56 === | ||
| + | |||
| + | Some fixes went to 4.12, namely scrub and auto-repair fixes. Feature marked as ''mostly OK'' for now. | ||
= Other = | = Other = | ||
Revision as of 13:01, 3 July 2017
Contents |
Overview
For a list of features by their introduction, please see the table Changelog#By_feature.
The table below aims to serve as an overview for the stability status of the features BTRFS supports. While a feature may be functionally safe and reliable, it does not necessarily mean that its useful, for example in meeting your performance expectations for your specific workload.
The table is based on the latest released linux kernel: 4.12
| Feature | Status | Notes |
|---|---|---|
| Performance | ||
| Trim (aka. discard) | OK | fstrim and mounted with -o discard (has performance implications) |
| Autodefrag | OK | |
| Defrag | mostly OK | extents get unshared (see below) |
| Compression, deduplication | ||
| Compression | mostly OK | (needs verification and source) auto-repair and compression may crash |
| Out-of-band dedupe | mostly OK | performance issues |
| File range cloning | mostly OK | (reflink), heavily referenced extents have a noticeable performance hit |
| Reliabillity | ||
| Auto-repair | OK | automatically repair from a correct spare copy if possible (dup, raid1, raid10) |
| Scrub | OK | |
| Scrub + RAID56 | mostly OK | |
| nodatacow | OK | Nodatacow does not checksum data, see Manpage/btrfs(5). |
| Device replace | mostly OK | gets stuck on devices with bad sectors |
| Balance | OK | |
| Block group profile | ||
| Single (block group profile) | OK | |
| DUP (block group profile) | OK | |
| RAID0 | OK | |
| RAID1 | mostly OK | Needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present. |
| RAID10 | mostly OK | Needs to be able to create two copies always. Can get stuck in irreversible read-only mode if only one copy can be made. |
| RAID56 | Unstable | write hole still exists, parity not checksummed |
| Mixed block groups | OK | see documentation |
| Administration | ||
| Filesystem resize | OK | shrink, grow |
| Offline UUID change | OK | |
| Subvolumes, snapshots | OK | |
| Send | OK | corner cases may still exist |
| Receive | OK | |
| Seeding | OK | should be better documented |
| Quotas, qgroups | mostly OK | |
| Misc | ||
| Free space tree | mostly OK | see below |
| no-holes | OK | see documentation for compatibility |
| skinny-metadata | OK | see documentation for compatibility |
| extended-refs | OK | see documentation for compatibility |
Legend:
- OK: should be safe to use, no known defficiencies
- mostly OK: safe for general use, there are some known problems
- Unstable: do not use for other then testing purposes, known severe problems, missing implementation of some core part
Note to editors:
This page reflects status of the whole project and edits need to be approved by one of the maintainers (kdave). Suggest edits if:
- there's a known missing entry
- a particular feature combination that has a different status and is worth mentioning separately
- you knouw of a bug that lowers the feature status
- a reference could be enhanced by an actual link to documentation (wiki, manual pages)
Details that do not fit the table
Defrag
The data affected by the defragmentation process will be newly written and will consume new space, the links to the original extents will not be kept. See also Manpage/btrfs-filesystem. Though autodefrag affects newly written data, it can read a few adjacent blocks (up to 64k) and write the contiguous extent to a new location. The adjacent blocks will be unshared. This happens on a smaller scale than the on-demand defrag and doesn't have the same impact.
Free space tree
- btrfs-progs support is read-only, ie. fsck can check the filesystem but is not able to keep the FST consistent and thus cannot run in repair mode
- the free space tree can be cleared using 'btrfs check --clear-space-cache v2' and will be rebuilt at next mount
Compatibility and historical references:
- btrfs-progs versions before v4.7.3 might accidentally do writes to the filesystem, but since there's no way to invalidate the FST, this causes inconsistency and possible corruption (using a piece of space twice). If you have made changes (btrfstune, repair, ...) to a FST enabled filesystem with btrfs progs, then mount with clear_cache,space_cache=v2 and hope the space written to was not reused yet. (see Status of free-space-tree feature)
- (fixed in linux 4.9) runtime support: fine on little-endian machines (x86*), known to be broken on big-endian (sparc64), see sparc64: btrfs module fails to load on big-endian machines
RAID56
Some fixes went to 4.12, namely scrub and auto-repair fixes. Feature marked as mostly OK for now.
Other
On-disk format
The filesystem disk format is stable. This means it is not expected to change unless there are very strong reasons to do so. If there is a format change, filesystems which implement the previous disk format will continue to be mountable and usable by newer kernels.
The core of the on-disk format that comprises building blocks of the filesystem:
- layout of the main data structures, eg. superblock, b-tree nodes, b-tree keys, block headers
- the COW mechanism, based on the original design of Ohad Rodeh's paper "Shadowing and clones"
Newly introduced features build on top of the above and could add specific structures. If a backward compatibility is not possible to maintain, a bit in the filesystem superblock denotes that and the level of incompatibility (full, read-only mount possible).
