9

I try to check the device containing /home and see:

$ sudo btrfs check --force /dev/vg_svelte/home
WARNING: filesystem mounted, continuing because of --force
ERROR: cannot open device '/dev/vg_svelte/home': Device or resource busy
ERROR: cannot open file system

Note: btrfs check is a read-only operation. Adding --repair is necessary to make any changes.

The btrfs-check man page indicates that it should work:

   --force
       allow to 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.

This question is about how to check a btrfs root filesystem.

Why can't I btrfs check --force without --repair on a mounted device?

I'm running Manjaro Linux.

Tom Hale
  • 30,455
  • This is a read-only operation Maybe?!?. The system keeps running and making changes to the file system in /. So, no you can not check a running OS's / from it's mounted /. –  Oct 16 '17 at 04:29
  • It fails on /home as well, so I updated the question. @Arrow the man page implies it should work on a quiescent device. I'd assume that if I run it a few times and get non-overlapping errors, it's not worth rebooting. – Tom Hale Oct 16 '17 at 04:41
  • @TomHale. Did you remount /home as read-only before trying? – fpmurphy Oct 17 '17 at 01:06

3 Answers3

3

As with other Linux filesystems (ext3, ext4, etc), the correct procedure for checking a btrfs root filesystem, is to boot the system from a LiveCD or a rescue USB/CD/USB and check the target filesystem while it is unmounted using utilities provided by the LiveCD.

fpmurphy
  • 4,636
  • 4
    But why is it "correct" if --check is a read-only operation? Adding --repair is necessary to make any changes. – Tom Hale Oct 16 '17 at 04:27
  • 1
    @TomHale. All activity on the root filesystem needs to be halted (quiesced) while it is checked. The read-only option does not do that. – fpmurphy Oct 17 '17 at 00:59
  • I get the same issue even when trying to check without --repair on a ro mounted /home filesystem. It seems to be a btrfs bug. – Tom Hale Oct 26 '17 at 10:57
2

With btrfs-progs v5.17, btrfs check --force now works on a mounted filesystem.

Tom Hale
  • 30,455
-1

To actually make corrections on the filesystem freely it has to be unmounted, so you can never do it on what you're running from. Live, rescue, sometimes you can do it from install media. Any Linux will do, it doesn't have to be the same kind, it just needs to know the filesystem type. I fsck Raspberry Pi SDs on an amd64 Debian laptop all the time. You will need to reboot.

Alan Corey
  • 247
  • 1
    --check is a read-only operation without --repair, so why should I need to reboot? – Tom Hale Oct 16 '17 at 04:28
  • I've never heard of btrfs but that's the way it works with fsck. You might be able to run badblocks on it. You don't specifically need to reboot, the file system just can't be mounted. If for example the system wrote something out to a swapfile and btrfs moved it as part of the checking process the system would probably crash. Blame it on the documentation for implying it's possible. Maybe in a later version it will be, a read-only test could be allowed. /home doesn't need to be mounted for testing, move it sometime. – Alan Corey Oct 19 '17 at 19:31
  • If you've never heard of btrfs, then why are you answering this question without first doing some research to answer the "why"? – Tom Hale Oct 20 '17 at 02:26
  • Because unless you're a magician or from some other dimension you can't modify any file system while it's in use, even in DOS. You set a check flag and it gets checked on next reboot before it's mounted. Not that one couldn't be written but the disk check would have to be merged into the kernel to coordinate everything. The tool is irrelevant otherwise. – Alan Corey Oct 21 '17 at 02:55
  • 1
    Again, I'm not trying to modify the filesystem. – Tom Hale Oct 21 '17 at 07:57
  • But your OS probably is. Which the checking program will probably see as an error if it runs into something changed since last time it looked. So it doesn't try if it's mounted. You might use --check without --repair if it was really critical data and you intended to back it up with something like dd before you tried a repair. Sometimes you do a repair on the backup copy and leave the original alone. dd just copies every sector, it doesn't look at stuff like where your inodes are pointing to or try to make sense of them. – Alan Corey Oct 26 '17 at 09:15
  • 1
    I get the same issue even when trying to check without --repair on a ro mounted filesystem. It seems to be a btrfs bug. – Tom Hale Oct 26 '17 at 10:56
  • I don't see why check would need to do any modification without --repair. I just want to know if there is an error that needs further action (for example a daily check if everything is in order). – zoechi Jul 15 '19 at 18:02