More details on the issue and a complete explantion you can find here:
(Help! I ran out of disk space! )
And an explantion for the "dlimit" solution:
Quote From: Uncommon solutions for BTRFS
> For my purposes, I define internal fragmentation as space allocated but not
> usable by the filesystem. In BTRFS, each time you delete files, the space
> used by those files cannot be reused for new files automatically.
> It's not a hard requirement to do this maintenance regularly, but doing it
> regularly spares you waiting for hours when the disk is full and you need to
> wait for a balance clean up command - and of course also reduces the number
> of > times you get unexpected disk full errors. As a side note, this can also
> be useful to prolong the life of your SSD because it allows the SSD to reuse
> space not needed by the filesystem (although there is a trade-off, frequent
> balancing is bad, no balancing is bad, the sweet spot is somewhere in
2016-09-20 10:20 GMT+02:00 Peter Becker <floyd....@gmail.com>:
> Normaly total and used should deviate us a few gb.
> depend on your write workload you should run
> btrfs balance start -dusage=60 /mnt
> every week to avoid "ENOSPC"
> if you use newer btrfs-progs who supper balance limit filters you should run
> btrfs balance start -dusage=99 -dlimit=10 /mnt
> every 3 hours.
> This will balance 2 Blocks (dlimit=10; corresponds to 10 gb) with are
> not filled full into new blocks. You could/should adjust the intervall
> and the limit-filter depend on your write workload.
> For example if you write (change files + new files) only 10GB a day it
> will be enough to run this ever night.
> The last option completly avoid the ENOSPC issue but produce aditional
> workload for your harddrives.
> Note: you should avoid making snapshots during balance. Use a simple
> lock-mechanic for that.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html