Are Btrfs-ckeck and scrub sure enough?

good morning,

I use Btrfs as my file system. I’ve read that you can run btrfs-ckeck and scrub.

Will these options break my system?

I’ve already read that btrfs-check isn’t safe yet, and indeed at the time I broke my file system with…

Have things changed since then? Or is it better to clone the whole disk first?

thanks to those who have experimented and to the others…

You should be running scrubs regularly. I usually schedule it to run monthly. It should be safe.

You may also need to run balance operations periodically. I usually run these monthly as well although that isn’t needed in many use cases. Be aware that performance will be degraded while the balance is running.

btrfs check is for error checking and repair. I am not aware that using it to check can cause errors but repair can definitely damage a filesystem and leave it in a worse case. I don’t run btrfs check unless the filesystem is reporting errors.

the difference of both is not clear to me…

Furthermore I don’t know what is balance… :frowning: .

btrfs has many advantages, but it’s also a little complex.

it’s a bit like going back to Windows with defrag :laughing:

A scrub does simple checksum validation and can only fix issues if replica data is available.

A check is more like fsck. The btrfs documentation states this:

Scrub is not a filesystem checker (fsck) and does not verify nor repair structural damage in the filesystem. It really only checks checksums of data and tree blocks, it doesn’t ensure the content of tree blocks is valid and consistent. There’s some validation performed when metadata blocks are read from disk but it’s not extensive and cannot substitute full btrfs check run.

An overly simplified answer would be that balance rearranges the data and metadata to make it more efficient.

well, btrfs-check is for the container, scrub is for the content, right ?

Not really, no.

You can simplify Btrfs administration by using a tool like btrfsmaintenance and setting up some systemd timers to automate it for you.

Even better, install the very excellent Btrfs Assistant application and just tick a few checkboxes in the GUI, then you are done.

This is really nice because you can basically just set it and forget it.

Btrfs Assistant also has an abundance of other useful utilities for managing snapshots and subvolumes. It makes restoring snapshots, or even individual files out of snapshots insanely easy. Still, if you don’t care about snapshots and just wanted to install it for the super convenient btrfsmaintenance integration I would say it’s worth it.

yay -S btrfsmaintenance btrfs-assistant

Both packages are available in the Chaotic AUR as well, if you’d rather install a prebuilt binary.

It’s perfectly safe, unless you run it with one of the flags under “dangerous options” in the documentation (the most common example would be “--repair”). btrfs-check is not run as part of normal system maintenance, rather as Dalto mentioned you would basically never run it unless your system was throwing filesystem errors.

ok, cool , thank you for your advice.

I was already using snapper and found some of Btrfs-assistant’s features relatively redundant. I wondered what the point of such a tool was.

But after installing btrfsmaintenance I see that Brtrfs-Assistant is in fact modular, so it becomes much more interesting.

Now, one last question that remains unanswered: is a btrfs-check with the possibility of repairing, but not recommended, useful only in case of despair?

btrfs check --repair and the other similar options should only be used after you have assessed what is wrong with your filesystem and determined what the correct course of action is. Btrfs is sophisticated enough that there may be a different solution that is a better option than --repair. Once your file system gets that corrupt, you are better off getting an expert involved. Of course, having backups of all your data so you won’t care that much if it gets corrupted is even better.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.