# btrfs free space cache error!

## Cyker

After one of my experiments with trying to get OpenCL to work locked up the system, I rebooted and noticed a slightly worrying warning in dmesg:

```
BTRFS warning (device sdc): block group 3590622019584 has wrong amount of free space

BTRFS warning (device sdc): failed to load free space cache for block group 3590622019584, rebuild it now

```

So, does it mean it is rebuilding it, or is it asking me to rebuild it?

If it's asking me to rebuild it, does it actually mean run some sort of equivalent of 

```
echo check >> /sys/block/md0/md/sync_action
```

 or... what?

I'm starting to realize I have absolutely no idea how to maintain my shiny new btrfs RAID5 system... halp!

----------

## eccerr0r

It sounds like it found an inconsistency and is asking you to fix it.

However I have never used btrfs before so I can't help with that.  You may need to unmount and mount with a recovery disk image and run btrfsck on the volume.

Now it sounds like you're running btrfs over mdraid?  These are two different layers, the "check" is actually doing a check of the parity of only mdraid, which is the underlying system.  It won't affect your btrfs at all (theoretically).  You should do that separately regardless, just to keep things consistent at the mdraid level.

----------

## Cyker

Nah, it's straight btrfs RAID5.

I used to use mdadm on my old system, and whenever I had any problems I could run that command to check the RAID array's consistency, or run an fsck.

I don't know if btrfs has an equivalent command.

Anyway, I remounted the filesystem and dmesg reported that this mystery free space cache is enabled again so I'm going to assume it fixed itself and ignore it!

----------

## vaxbrat

While you can continue to use mdadm with btrfs, it isn't really necessary.  btrfs can work with bare drives (no partitions even) to handle all of the raiding and will automatically do a repair write when reading a sector and encountering a checksum error.  This checksum is in the metadata part of btrfs and not part of the low level ECC that the hard drive is using.  zfs has a similar automatic repair capability.

Instead of doing scrubbing by hand by poking stuff into mdadm's /proc interface use "btrs scrub" on a filesystem.  This is a userland background process that can be started, canceled and resumed.

Use "btrfs balance" on a filesystem as a user process (also pauseable and cancelable) to do optimize and something like an online fsck for a running filesystem.  It would have done the same thing that the mount on your next boot did to clean up the freespace cache.

If you really want to be silly, you can follow me into using ceph to distribute and replicate objects over multiple btrfs arrays.  ceph automatically schedules "lite" and "deep" scrubs of its "placement groups" so you don't even need to worry about scheduling scrubs anymore.  Also you can lose one or more raid arrays due to failure (up to whatever you have set for replication count) and still be able to replace and recover.

----------

## davidm

Btrfs RAID5 or RAID6 is not currently generally recommended.  It's considered highly unstable.  From what I understand the repair tools for it basically do not function.  See https://btrfs.wiki.kernel.org/index.php/RAID56

 *Quote:*   

> 
> 
> Raid 5 and Raid6 are mostly working as of 3.9, but the recovery and rebuild code isn't bulletproof or complete yet.
> 
> If you'd like to learn btrfs raid5/6 and rebuilds by example (based on kernel 3.14), you can look at Marc MERLIN's page about btrfs raid 5/6.
> ...

 

----------

