6

I'm sure the reason I'm having a brain fart is because it's late, but how can I go about performing a btrfs check on the root partition?

The device needs to be unmounted, which can't happen because it's the root partition...

Thanks

Improve this question

3 Answers 3

Reset to default
4

If you're using systemd, you can pass the kernel parameter fsck.mode=force to check all filesystems. This will repair all "safe" errors.

If you still have issues (check your logs), pass fsck.repair=yes in addition to the above, which will attempt to repair everything.

For the source of this and other options (eg shutdown -F) for upstart and sysvinit init, see here.

Improve this answer
1
  • 2
    Warning: fsck for the btrfs filesystem is just a stub, it does nothing and returns success: man7.org/linux/man-pages/man8/fsck.btrfs.8.html Use "btrfs check" command, you HAVE to unmount the filesystem. There is no other way.
    – lzap
    Oct 22, 2022 at 14:54
1

Boot from a livecd and perform the check from there.

Improve this answer
7
  • Is that the ONLY way?
    – Dave
    Dec 10, 2015 at 23:54
  • You need to run some operating system from RAM. Using a livecd is a very simple way to do that.
    – EEAA
    Dec 10, 2015 at 23:55
  • 1
    It's a server, that's why I'm concerned. Thank you for the input :)
    – Dave
    Dec 10, 2015 at 23:59
  • 1
    Is that the ONLY way? - Well if you had a spare filesystem, you could copy any essential files to perform the check to another filesystem, then do a piviot_root() to the new filesystem. Perform the check and pivot back. But if you don't know what this means, and your system isn't already setup for it, then doing this will almost certainly be an order of magnitude more complicated then using a livecd.
    – Zoredache
    Dec 11, 2015 at 0:12
  • 1
    @Zoredache You're right on both counts. You can copy to a spare, but, IMO, it should be on a separate physical disk (e.g. current disk might be in "early fail" mode). Also, copying from a corrupted FS can make it more corrupt sometimes. Livecd is the way to go, and if I were OP, I'd take the server offline ASAP and boot the livecd ASAP. I've had to deal with massive corruption before (inc. replacing partially failing disks) and OP's situation is not one to be fooling around with
    – Craig Estey
    Dec 11, 2015 at 0:22
1

WARNING: The fsck.btrfs utility DOES NOTHING and returns success! The manual page explains that a separate command btrfs check must be used. See here: https://man7.org/linux/man-pages/man8/fsck.btrfs.8.html

The only way to check BTRFS system is to use its own tool btrfs check, you must have the root volume unmounted therefore the only option is to really boot from a livecd.

Any advice that ultimately leads to calling fsck.btrfs is plain wrong and dangerous, this is just a stub that prints out a message and does nothing. This includes answers with fsck.mode kernel command line options or .forcefsck files as well.

[root@nuc ~]# cat /usr/sbin/fsck.btrfs
#!/usr/bin/sh -f
AUTO=false
while getopts ":aApy" c
do
    case $c in
    a|A|p|y)    AUTO=true;;
    esac
done
shift $(($OPTIND - 1))
eval DEV=\${$#}
if [ ! -e $DEV ]; then
    echo "$0: $DEV does not exist"
    exit 8
fi
if ! $AUTO; then
    echo "If you wish to check the consistency of a BTRFS filesystem or"
    echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'."
fi
exit 0

However if you are just unsure if everything is okay after poweroutage or something like that, btrfs check can perform a readonly check on a mounted filesystem:

[root@nuc ~]# btrfs check --readonly --force /dev/sda5
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda5
UUID: 8c44de9c-c91b-4ac4-857b-da191dc62274
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 3628683264 bytes used, no error found
total csum bytes: 3093864
total tree bytes: 136937472
total fs tree bytes: 126074880
total extent tree bytes: 6455296
btree space waste bytes: 23047273
file data blocks allocated: 5676253184
 referenced 4705763328
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .