Re: some principal questions to "disk full"

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Wed, May 26, 2021 at 11:41:02AM +0200, Lentes, Bernd wrote:
> 
> 
> ----- On May 26, 2021, at 7:36 AM, arvidjaar arvidjaar@gmail.com wrote:
> 
> > On 25.05.2021 19:20, Lentes, Bernd wrote:
>  
> 
> >> What can i do to prevent a "disk full" situation ?
> >> Running regulary "btrfs balance" in a cron job ?

Run

	btrfs balance start -dlimit=1 /path/to/your/fs

about once a day.  This will force the filesystem to free up some
allocated but unused space in data chunks, making them unallocated.
This will ensure you have enough unallocated space to allow you to
allocate a new metadata chunk when needed.

btrfs might allocate a new metadata chunk at any time, so it is a good
idea to ensure at least 1GB (preferably 5 or 10 GB) is always unallocated.
The filesystem does have workarounds that will let it continue to work
with very low disk space, but they can degrade performance, increase
write wear, and increase exposure to firmware bugs if your drive has them.

Never balance metadata (full balance or btrfs balance start -m) from a
maintenance script.  This will free metadata chunks and lead directly to
ENOSPC gotchas.  The kernel deals with metadata allocations fairly well
for most users--but only if you don't break it with metadata balances.

If possible, resize your filesystem to about 5GB less than the underlying
device size.  That way, if you get stuck with low space for metadata, you
can do 'btrfs fi resize 1:max /fs' to get some quick and safe emergency
space to complete a balance or a snapshot delete.  Don't forget to resize
back to 5GB less than full size when the crisis is resolved.

> > If you are using more or less recent kernel version, you need not run
> > btrfs balance at all except when possibly converting profiles or adding
> > new device. btrfs became reasonably good at managing free space.
> 
> What is "more or less recent" ? Which version numbers ?

3.18 or later.  It's certainly not a new feature.

> Bernd