How to btrfs check a root partition

partclone is the tool you are looking for.

• it supports a lot of linux file systems, including BTRFS
• it even supports some other filesystems (like FAT or exFAT)
• unlike dd it looks at the file systems allocation map (e.g.: FAT and exFAT's FAT tables, BTRFS extent maps, etc.) and clones only the used blocks.

Depending on your usage pattern:

• use the -b (long: --dev-to-dev) if both source and backup target black device are visible on the same machine (basically if both disks are plugged into the same computer).
• or use -c and -r (long: --clone and --restore) to first clone to partclone's own image format on the source machine, and then restore from the image on the backup machine
• according to partclone manpage, it's possible to pipe images, so it should be possible to copy partitions over the network without saving actual files, if you're running short on space, but have an extremely reliable network.

A completely different way to handle the problem would be using btrfs send and btrfs receive mechanism.

• This WON'T produce block device copies down to the sector
• but, by correctly providing references on both ends, it is also able to keep the references between ref-linked (parts of) files.

So btrfs' own mechanism isn't a sector perfect copy (unlike partclone's) but it's an extent perfect copy (much better than rsynv -aSHAX which only handles hardlinked files).

From the sounds of it, you're running into this:

Allocation is done on a round-robin basis. If you have a raid1 strategy on a volume made up of mismatched drives (volumes of differing sizes), your smaller volume may fill up while leaving lots of space free on your single largest drive. You can verify that this is an issue if there is any discrepancy between 'df' and 'btrfs filesystem df [mountpoint]' AND if the latter command also shows that "total" and "used" are the same on the "Data" line. A rebalance may mitigate this problem. (2.6.33)

• If your volume does fill up in this manner, a rebalance may quickly cause an ENOSPC ("Error NO SPaCe left on device") oops. You may have to delete a relatively large file to resolve this impasse, then a rebalance will succeed. (2.6.33)

https://btrfs.wiki.kernel.org/index.php/Gotchas

Emphassis mine. The second partition on a third 80GB drive you mention is probably filling up well before the pair of 250GB drives are, and it's triggering this particular Gotcha.

Also, BTrFS is a beta filesystem for a reason.