>its metadata system that you have to manually resize constantly ? Doesn't ring a bell. A lot of problems with Btrfs sounds like hardware problems of one sor

>its metadata system that you have to manually resize constantly ? Doesn't ring a bell. A lot of problems with Btrfs sounds like hardware problems of one sort or another. If it's a legit bug the only way such things get fixed is to report it to the developers <linux-btrfs@vger.kernel.org> with complete logs and system information. Did you? The fsck is definitely hit or miss, but my perspective is the emphasis is on fixing bugs that obviate file system problems in the first place. The reality is an offline fsck for large file systems is just not scalable, so the best bang for the buck is bug squashing. And there's a tons of that happening. For the initial 4.12 pull (now done, and probably had a few dozen changes during rc's) 40 files changed, 1629 insertions(+), 834 deletions(-) https://lkml.org/lkml/2017/5/9/510 https://lkml.org/lkml/2017/5/9/510 For the initial 4.13 pull 47 files changed, 1707 insertions(+), 1400 deletions(-) https://lkml.org/lkml/2017/7/4/436 https://lkml.org/lkml/2017/7/4/436