This has been reported in the btrfs mailing list (search for the subject 6TB partition, Data only 2TB - aka When you haven't hit the "usual" problem).Here is a likely bug report: https://bugzilla.kernel.org/show_bug.cgi?id=74101 The bug would only happen after some time, so I was able to move a lot of data onto the fs before btrfs crashed, and then it was just a case of unmounting and mounting again.Yes, the obviously critical fixes get to the latest stable kernel and sometimes get also applied to the long-term branches.A sequence like this: By default the file system is mounted with relatime flag, which means it must update files' metadata during first access on each day.Since updates to metadata are done as COW, if one visits a lot o files, it results in massive and scattered write operations on the underlying media.See the Problem FAQ for commonly-encountered problems and solutions.
A CC of the linux-btrfs mailinglist is a good idea when there are patches selected for a particular longterm kernel and requested for addition to stable trees.
If you have full up metadata, and more than 1 Gi B of space free in data, as reported by btrfs fi df, then you should be able to free up some of the data allocation with a partial balance: We know this isn't ideal, and there are plans to improve the behavior.
Running close to empty is rarely the ideal case, but we can get far closer to full than we do. skip it If you see something like this when mounting: then you should run btrfs check on your fs.
Explicitly said: please report bugs and issues to the mailing list (you are not required to subscribe). Your hard drive has been detected as not supporting barriers.
This is a severe condition, which can result in full file-system corruption, not just losing or corrupting data that was being written at the time of the power cut or crash.