Re: BTRF: no free space

[Roman Mamedov <rm@romanrm.net>]

On Sun, 22 Oct 2023 12:43:57 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> this is a *new* filesystem and somewhere in the middle of the night at 
> 10% usage a large rsync stopped because BTRF thinks the filesystem is 
> full - how is this possible in 2023?
> 
> Metadata, DUP: total=1.00GiB, used=945.61MiB
> 
> -----------------
> 
> defaults,noatime,compress-force=zstd:15,ssd,ssd_spread,nodiscard,nobarrier,noexec,nosuid,nodev,commit=60
> 
> adding "clear_cache" which solved such issues in the past eve refuses to 
> mount it
> 
> [root@arrakisvm:~]$ mount /mnt/fileserver-backup/
> mount: /mnt/fileserver-backup: mount(2) system call failed: No space 
> left on device.
> 
> -----------------
> 
> [root@arrakisvm:~]$ df
> Filesystem     Type   Size  Used Avail Use% Mounted on
> /dev/sdd1      btrfs  2.0T  209G     0 100% /mnt/fileserver-backup
> 
> [root@arrakisvm:~]$ btrfs fi df /mnt/fileserver-backup
> Data, single: total=1.95TiB, used=207.05GiB
> System, DUP: total=8.00MiB, used=224.00KiB
> Metadata, DUP: total=1.00GiB, used=945.61MiB
> GlobalReserve, single: total=512.00MiB, used=0.00B

1) Report your kernel version

2) Retry without "ssd" and especially without "ssd_spread". The weird thing
here is that it appears the FS has allocated the entire unused space as "data"
chunks, leaving no space for any new metadata chunk. Personally I don't have
any other guess for the cause aside from the rarely-used (and little-tested?)
ssd_spread option. Of course still a bug even if so.

-- 
With respect,
Roman