Before trying fsck
If you have a broken filesystem, you should probably look at the recovery or repair tools or you can read Marc MERLIN's page that explains the different ways to check and fix a btrfs filesystem.
In a nutshell, you should look at:
- btrfs scrub to detect issues on live filesystems
- look at btrfs detected errors in syslog (look at Marc's blog above on how to use sec.pl to do this)
- mount -o ro,recovery to mount a filesystem with issues
- btrfs-zero-log might help in specific cases. Go read Btrfs-zero-log
- btrfs restore will help you copy data off a broken btrfs filesystem. See its page: Restore
- btrfs check --repair, aka btrfsck is your last option if the ones above have not worked.
btrfs check --repair
btrfs check --repair (used to be called btrfsck) checks consistency of a btrfs filesystem, and optionally repair some types of breakage. It can only be run on an unmounted FS.
Note that while this tool should be able to repair broken filesystems, it is still relatively new code, and has not seen widespread testing on a large range of real-life breakage. It is possible that it may cause additional damage in the process of repair. btrfs check --repair has been greatly improved from the 3.x kernels, you really want to run a version of btrfs-tools 4.0 or later for better repairs.
It is highly recommended to get the latest version of btrfs-tools and recover important data with the steps listed above (mount -o recovery,ro and btrfs restore) before trying btrfs check --repair
btrfs check --repair <device>
See the man page for exact up to date usage info: Manpage/btrfs-check
If all goes well, it should look something like this:
gargamel:/mnt# btrfs check --repair /dev/mapper/space 2>&1 | tee /tmp/repair Fixed 0 roots. checking extents checking free space cache checking fs roots checking csums checking root refs enabling repair mode Checking filesystem on /dev/mapper/space UUID: 77077815-4ca2-44cd-a83a-b1aeb4607df4 cache and super generation don't match, space cache will be invalidated found 294976426877 bytes used err is 0 total csum bytes: 636680648 total tree bytes: 6981910528 total fs tree bytes: 5149491200 total extent tree bytes: 895369216 btree space waste bytes: 1860661732 file data blocks allocated: 651971338240 referenced 676102934528 Btrfs v3.17
For comparison, the old obsolete btrfsck looks like this:
gargamel:/mnt/btrfs_pool1# btrfsck /dev/mapper/raid0d1 Checking filesystem on /dev/mapper/raid0d1 UUID: 7f0c0b97-befe-4183-ab33-dba5b0059c3a checking extents checking free space cache checking fs roots checking csums checking root refs found 15735927605 bytes used err is 0 total csum bytes: 626165256 total tree bytes: 3327885312 total fs tree bytes: 2231566336 total extent tree bytes: 352927744 btree space waste bytes: 499663388 file data blocks allocated: 641351032832 referenced 648040566784
My personal experience with the old btrfsck is that it could run for 24H or more on a filesystem of a few terabytes, and look like it's never going to complete. In my experience it's also not unusual to get tens to over a hundred thousand lines of output showing lines like:
Extent back ref already exists for 2148837945344 parent 0 root 257 leaf parent key incorrect 504993210368 bad block 504993210368
FIXME: are those real problems or unfortunate real problems that easily happen btrfs filesystems?