On Mon, Sep 4, 2017 at 7:19 AM, Russell Coker <russell+btrfs@xxxxxxxxxxxx> wrote: > I have a system with less than 50% disk space used. It just started rejecting > writes due to lack of disk space. I ran "btrfs balance" and then it started > working correctly again. It seems that a btrfs filesystem if left alone will > eventually get fragmented enough that it rejects writes (I've had similar > issues with other systems running BTRFS with other kernel versions). > > Is this a known issue? This is a known issue, but with kernel 4.8 or later it more rare. At least I myself have never had it since then on 10+ active btrfs filesystems. > Is there any good way of recognising when it's likely to happen? Is there > anything I can do other than rewriting a medium size file to determine when > it's happened? I am not aware of an easy way of recognizing it, but there are some python tools that can show you the usage per chunk and that can give an indication. A way to prevent the issue might be adding/changing mount options, although I have no hard proof, only good experiences. What are the mount options fpor this filesystem? I think compress=lzo, noatime, and autodefrag might help for various reasons. I use the first 2 on SSDs en the last one on HDDs (with and without bcache). Maybe someone else has more tips or comments. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
