mirror of
https://github.com/kdave/btrfs-progs
synced 2024-12-12 09:26:31 +00:00
2b3d95519e
There are several warnings regarding the absence of an argument for the
code-block directive on some build servers using python3-sphinx 0.2.2-17.
For example:
Making all in Documentation
[SPHINX] man
ch-subvolume-intro.rst:141: WARNING: Error in "code-block" directive:
1 argument(s) required, 0 supplied.
.. code-block::
27 21 0:19 /subv1 /mnt rw,relatime - btrfs /dev/sda rw,space_cache
Etc...
Add the none argument.
[ci skip]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
86 lines
4.3 KiB
ReStructuredText
86 lines
4.3 KiB
ReStructuredText
Tree checker
|
|
============
|
|
|
|
Tree checker is a feature that verifies metadata blocks before write or after
|
|
read from the devices. The b-tree nodes contain several items describing the
|
|
filesystem structures and to some degree can be verified for consistency or
|
|
validity. This is an additional check to the checksums that only verify the
|
|
overall block status while the tree checker tries to validate and cross
|
|
reference the logical structure. This takes a slight performance hit but is
|
|
comparable to calculating the checksum and has no noticeable impact while it
|
|
does catch all sorts of errors.
|
|
|
|
There are two occasions when the checks are done:
|
|
|
|
Pre-write checks
|
|
----------------
|
|
|
|
When metadata blocks are in memory and about to be written to the permanent
|
|
storage, the checks are performed, before the checksums are calculated. This
|
|
can catch random corruptions of the blocks (or pages) either caused by bugs or
|
|
by other parts of the system or hardware errors (namely faulty RAM).
|
|
|
|
Once a block does not pass the checks, the filesystem refuses to write more data
|
|
and turns itself to read-only mode to prevent further damage. At this point some
|
|
the recent metadata updates are held *only* in memory so it's best to not panic
|
|
and try to remember what files could be affected and copy them elsewhere. Once
|
|
the filesystem gets unmounted, the most recent changes are unfortunately lost.
|
|
The filesystem that is stored on the device is still consistent and should mount
|
|
fine.
|
|
|
|
A message may look like:
|
|
|
|
.. code-block:: none
|
|
|
|
[ 1716.823895] BTRFS critical (device vdb): corrupt leaf: root=18446744073709551607 block=38092800 slot=0, invalid key objectid: has 1 expect 6 or [256, 18446744073709551360] or 18446744073709551604
|
|
[ 1716.829499] BTRFS info (device vdb): leaf 38092800 gen 19 total ptrs 4 free space 15851 owner 18446744073709551607
|
|
[ 1716.832891] BTRFS info (device vdb): refs 3 lock (w:0 r:0 bw:0 br:0 sw:0 sr:0) lock_owner 0 current 1506
|
|
[ 1716.836054] item 0 key (1 1 0) itemoff 16123 itemsize 160
|
|
[ 1716.837993] inode generation 1 size 0 mode 100600
|
|
[ 1716.839760] item 1 key (256 1 0) itemoff 15963 itemsize 160
|
|
[ 1716.841742] inode generation 4 size 0 mode 40755
|
|
[ 1716.843393] item 2 key (256 12 256) itemoff 15951 itemsize 12
|
|
[ 1716.845320] item 3 key (18446744073709551611 48 1) itemoff 15951 itemsize 0
|
|
[ 1716.847505] BTRFS error (device vdb): block=38092800 write time tree block corruption detected
|
|
|
|
The line(s) before the *write time tree block corruption detected* message is
|
|
specific to the found error.
|
|
|
|
Post-read checks
|
|
----------------
|
|
|
|
Metadata blocks get verified right after they're read from devices and the
|
|
checksum is found to be valid. This protects against changes to the metadata
|
|
that could possibly also update the checksum, less likely to happen accidentally
|
|
but rather due to intentional corruption or fuzzing.
|
|
|
|
.. code-block:: none
|
|
|
|
[ 4823.612832] BTRFS critical (device vdb): corrupt leaf: root=7 block=30474240 slot=0, invalid nritems, have 0 should not be 0 for non-root leaf
|
|
[ 4823.616798] BTRFS error (device vdb): block=30474240 read time tree block corruption detected
|
|
|
|
The checks
|
|
----------
|
|
|
|
As implemented right now, the metadata consistency is limited to one b-tree node
|
|
and what items are stored there, i.e. there's no extensive or broad check done
|
|
e.g. against other data structures in other b-tree nodes. This still provides
|
|
enough opportunities to verify consistency of individual items, besides verifying
|
|
general validity of the items like the length or offset. The b-tree items are
|
|
also coupled with a key so proper key ordering is also part of the check and can
|
|
reveal random bitflips in the sequence (this has been the most successful
|
|
detector of faulty RAM).
|
|
|
|
The capabilities of tree checker have been improved over time and it's possible
|
|
that a filesystem created on an older kernel may trigger warnings or fail some
|
|
checks on a new one.
|
|
|
|
Reporting problems
|
|
------------------
|
|
|
|
In many cases the bug is caused by hardware and cannot be automatically fixed
|
|
by *btrfs check --repair*, so do not try that without being advised to. Even if
|
|
the error is unfixable it's useful to report it, either to validate the cause
|
|
but also to give more ideas how to improve the tree checker. Please consider
|
|
reporting it to the mailing list *linux-btrfs@vger.kernel.org*.
|