Manpage/btrfs-check

From btrfs Wiki
(Difference between revisions)
Jump to: navigation, search
(git 5.4)
(remove content)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
=btrfs-check(8) manual page=
 
 
{{GeneratedManpage
 
{{GeneratedManpage
 
|name=btrfs-check}}
 
|name=btrfs-check}}
 
==NAME==
 
btrfs-check - check or repair a btrfs filesystem
 
 
==SYNOPSIS==
 
 
<p><b>btrfs check</b> [options] <em>&lt;device&gt;</em></p>
 
==DESCRIPTION==
 
 
<p>The filesystem checker is used to verify structural integrity of a filesystem
 
and attempt to repair it if requested.  It is recommended to unmount the
 
filesystem prior to running the check, but it is possible to start checking a
 
mounted filesystem (see <em>--force</em>).</p>
 
<p>By default, <b>btrfs check</b> will not modify the device but you can reaffirm that
 
by the option <em>--readonly</em>.</p>
 
<p><b>btrfsck</b> is an alias of <b>btrfs check</b> command and is now deprecated.</p>
 
<blockquote><b>Warning:</b>
 
Do not use <em>--repair</em> unless you are advised to do so by a developer
 
or an experienced user, and then only after having accepted that no <em>fsck</em>
 
successfully repair all types of filesystem corruption. Eg. some other software
 
or hardware bugs can fatally damage a volume.</blockquote>
 
<p>The structural integrity check verifies if internal filesystem objects or
 
data structures satisfy the constraints, point to the right objects or are
 
correctly connected together.</p>
 
<p>There are several cross checks that can detect wrong reference counts of shared
 
extents, backreferences, missing extents of inodes, directory and inode
 
connectivity etc.</p>
 
<p>The amount of memory required can be high, depending on the size of the
 
filesystem, similarly the run time. Check the modes that can also affect that.</p>
 
==SAFE OR ADVISORY OPTIONS==
 
 
<dl>
 
<dt>
 
-b|--backup
 
<dd>
 
<p>
 
use the first valid set of backup roots stored in the superblock
 
</p>
 
<p>This can be combined with <em>--super</em> if some of the superblocks are damaged.</p>
 
 
<dt>
 
--check-data-csum
 
<dd>
 
<p>
 
verify checksums of data blocks
 
</p>
 
<p>This expects that the filesystem is otherwise OK, and is basically and offline
 
<em>scrub</em> but does not repair data from spare copies.</p>
 
 
<dt>
 
--chunk-root <em>&lt;bytenr&gt;</em>
 
<dd>
 
<p>
 
use the given offset <em>bytenr</em> for the chunk tree root
 
</p>
 
 
<dt>
 
-E|--subvol-extents <em>&lt;subvolid&gt;</em>
 
<dd>
 
<p>
 
show extent state for the given subvolume
 
</p>
 
 
<dt>
 
-p|--progress
 
<dd>
 
<p>
 
indicate progress at various checking phases
 
</p>
 
 
<dt>
 
-Q|--qgroup-report
 
<dd>
 
<p>
 
verify qgroup accounting and compare against filesystem accounting
 
</p>
 
 
<dt>
 
-r|--tree-root <em>&lt;bytenr&gt;</em>
 
<dd>
 
<p>
 
use the given offset <em>bytenr</em> for the tree root
 
</p>
 
 
<dt>
 
--readonly
 
<dd>
 
<p>
 
(default)
 
run in read-only mode, this option exists to calm potential panic when users
 
are going to run the checker
 
</p>
 
 
<dt>
 
-s|--super <em>&lt;superblock&gt;</em>
 
<dd>
 
<p>
 
use 'superblock&#8217;th superblock copy, valid values are 0, 1 or 2 if the
 
respective superblock offset is within the device size
 
</p>
 
<p>This can be used to use a different starting point if some of the primary
 
superblock is damaged.</p>
 
 
<dt>
 
--clear-space-cache v1|v2
 
<dd>
 
<p>
 
completely wipe all free space cache of given type
 
</p>
 
<p>For free space cache <em>v1</em>, the <em>clear_cache</em> kernel mount option only rebuilds
 
the free space cache for block groups that are modified while the filesystem is
 
mounted with that option. Thus, using this option with <em>v1</em> makes it possible
 
to actually clear the entire free space cache.</p>
 
<p>For free space cache <em>v2</em>, the <em>clear_cache</em> kernel mount option destroys
 
the entire free space cache. This option, with <em>v2</em> provides an alternative
 
method of clearing the free space cache that doesn&#8217;t require mounting the
 
filesystem.</p>
 
 
</dl>
 
==DANGEROUS OPTIONS==
 
 
<dl>
 
<dt>
 
--repair
 
<dd>
 
<p>
 
enable the repair mode and attempt to fix problems where possible
 
</p>
 
<blockquote><b>Note:</b>
 
there&#8217;s a warning and 10 second delay when this option is run without
 
<em>--force</em> to give users a chance to think twice before running repair, the
 
warnings in documentation have shown to be insufficient</blockquote>
 
 
<dt>
 
--init-csum-tree
 
<dd>
 
<p>
 
create a new checksum tree and recalculate checksums in all files
 
</p>
 
<blockquote><b>Note:</b>
 
Do not blindly use this option to fix checksum mismatch problems.</blockquote>
 
 
<dt>
 
--init-extent-tree
 
<dd>
 
<p>
 
build the extent tree from scratch
 
</p>
 
<blockquote><b>Note:</b>
 
Do not use unless you know what you&#8217;re doing.</blockquote>
 
 
<dt>
 
--mode <em>&lt;MODE&gt;</em>
 
<dd>
 
<p>
 
select mode of operation regarding memory and IO
 
</p>
 
<p>The <em>MODE</em> can be one of:</p>
 
<dl>
 
<dt>
 
<em>original</em>
 
<dd>
 
<p>
 
The metadata are read into memory and verified, thus the requirements are high
 
on large filesystems and can even lead to out-of-memory conditions.  The
 
possible workaround is to export the block device over network to a machine
 
with enough memory.
 
</p>
 
 
<dt>
 
<em>lowmem</em>
 
<dd>
 
<p>
 
This mode is supposed to address the high memory consumption at the cost of
 
increased IO when it needs to re-read blocks.  This may increase run time.
 
</p>
 
<blockquote><b>Note:</b>
 
<em>lowmem</em> mode does not work with <em>--repair</em> yet, and is still considered
 
experimental.</blockquote>
 
 
</dl>
 
 
<dt>
 
--force
 
<dd>
 
<p>
 
allow work on a mounted filesystem. Note that this should work fine on a
 
quiescent or read-only mounted filesystem but may crash if the device is
 
changed externally, eg. by the kernel module.  Repair without mount checks is
 
not supported right now.
 
</p>
 
<p>This option also skips the delay and warning in the repair mode (see
 
<em>--repair</em>).</p>
 
 
</dl>
 
==EXIT STATUS==
 
 
<p><b>btrfs check</b> returns a zero exit status if it succeeds. Non zero is
 
returned in case of failure.</p>
 
==AVAILABILITY==
 
 
<p><b>btrfs</b> is part of btrfs-progs.
 
Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for
 
further details.</p>
 
==SEE ALSO==
 
 
<p>[[Manpage/mkfs.btrfs|mkfs.btrfs(8)]],
 
[[Manpage/btrfs-scrub|btrfs-scrub(8)]],
 
[[Manpage/btrfs-rescue|btrfs-rescue(8)]]</p>
 
[[Category:Manpage]]
 

Latest revision as of 12:28, 12 January 2022

Note: manual pages are located at read-the-docs site, please update your links.


Personal tools