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

Dave
  • 61
  • 1
  • 2

3 Answers3

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.

Tom Hale
  • 1,005
  • 1
  • 12
  • 23
1

Boot from a livecd and perform the check from there.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • Is that the ONLY way? – Dave Dec 10 '15 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 '15 at 23:55
  • 1
    It's a server, that's why I'm concerned. Thank you for the input :) – Dave Dec 10 '15 at 23:59
  • Well that should be all the more reason to take the thing down and ensure the filesystem is healthy. Make sure you verify that you have good backups before you do anything. – EEAA Dec 11 '15 at 00:00
  • @Dave Usually, most distros make it easy to create a livecd [if you don't have one already]. IIRC, a distro install livecd has either a rescue boot, or can give you a shell [and will cross mount on /sysimage--which you can unmount and do the fsck on the underlying /dev entry]. And, you can usually create a liveusb as well, if that's more convenient. Also, btrfs is pretty good at online self healing, so how do you know you need an fsck [which, at present, must be done offline--online a future feature]? – Craig Estey Dec 11 '15 at 00:01
  • 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 '15 at 00: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 '15 at 00:22
0

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 wrong, 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
lzap
  • 2,704
  • 2
  • 22
  • 22