[opensuse] Problem with Btrfs - it thinks disk is full
Hi, I installed twice new TW system (once after replacement of disk) using TW snapshot 20200205 image. Installation went fine, but on running system I repeatedly run into problems with 'df -h' showing no space available, but 'sudo btrfs fi show /' correctly showing plenty of space. The answer is in 'sudo btrfs fi df /' showing I'm (nearly) running out of space of Metadata: $ df -h Souborový systém Velikost Užito Volno Uži% Připojeno do devtmpfs 12G 0 12G 0% /dev tmpfs 12G 111M 12G 1% /dev/shm tmpfs 12G 1,7M 12G 1% /run tmpfs 12G 0 12G 0% /sys/fs/cgroup /dev/mapper/pocitac-koren 3,5T 759G 0 100% / /dev/mapper/pocitac-koren 3,5T 759G 0 100% /.snapshots /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/x86_64-efi /dev/mapper/pocitac-koren 3,5T 759G 0 100% /opt /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/i386-pc /dev/mapper/pocitac-koren 3,5T 759G 0 100% /root /dev/mapper/pocitac-koren 3,5T 759G 0 100% /usr/local /dev/mapper/pocitac-koren 3,5T 759G 0 100% /tmp /dev/mapper/pocitac-koren 3,5T 759G 0 100% /var /dev/mapper/pocitac-koren 3,5T 759G 0 100% /home /dev/mapper/pocitac-koren 3,5T 759G 0 100% /srv /dev/sda1 300M 8,1M 292M 3% /boot/efi tmpfs 2,4G 0 2,4G 0% /run/user/65534 tmpfs 2,4G 16K 2,4G 1% /run/user/1000 $ sudo btrfs fi show / Label: 'korinek' uuid: df8db051-fb0b-4d70-b4cb-3126d757f544 Total devices 1 FS bytes used 758.09GiB devid 1 size 3.48TiB used 760.03GiB path /dev/mapper/pocitac-koren $ sudo btrfs fi df / [sudo] heslo pro root: Data, single: total=757.00GiB, used=755.49GiB System, single: total=32.00MiB, used=112.00KiB Metadata, single: total=3.00GiB, used=2.57GiB GlobalReserve, single: total=512.00MiB, used=0.00B The numbers keep changing, so it's not super up-to-date, but I hope the problem is obvious. Fix is possible by using 'sudo btrfs balance start /' - it usually enlarges limit for Metadata. I never had such issue on older system (updated to the same TW snapshot), but I keep having it regularly on new installs. Is it some known bug with Btrfs, or should I report it? Yours, V. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On 2020-02-09 20:09, Vojtěch Zeisek wrote:
Hi, I installed twice new TW system (once after replacement of disk) using TW snapshot 20200205 image. Installation went fine, but on running system I repeatedly run into problems with 'df -h' showing no space available, but 'sudo btrfs fi show /' correctly showing plenty of space. The answer is in 'sudo btrfs fi df /' showing I'm (nearly) running out of space of Metadata: $ df -h Souborový systém Velikost Užito Volno Uži% Připojeno do devtmpfs 12G 0 12G 0% /dev tmpfs 12G 111M 12G 1% /dev/shm tmpfs 12G 1,7M 12G 1% /run tmpfs 12G 0 12G 0% /sys/fs/cgroup /dev/mapper/pocitac-koren 3,5T 759G 0 100% / /dev/mapper/pocitac-koren 3,5T 759G 0 100% /.snapshots /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/x86_64-efi /dev/mapper/pocitac-koren 3,5T 759G 0 100% /opt /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/i386-pc /dev/mapper/pocitac-koren 3,5T 759G 0 100% /root /dev/mapper/pocitac-koren 3,5T 759G 0 100% /usr/local /dev/mapper/pocitac-koren 3,5T 759G 0 100% /tmp /dev/mapper/pocitac-koren 3,5T 759G 0 100% /var /dev/mapper/pocitac-koren 3,5T 759G 0 100% /home /dev/mapper/pocitac-koren 3,5T 759G 0 100% /srv /dev/sda1 300M 8,1M 292M 3% /boot/efi tmpfs 2,4G 0 2,4G 0% /run/user/65534 tmpfs 2,4G 16K 2,4G 1% /run/user/1000 $ sudo btrfs fi show / Label: 'korinek' uuid: df8db051-fb0b-4d70-b4cb-3126d757f544 Total devices 1 FS bytes used 758.09GiB devid 1 size 3.48TiB used 760.03GiB path /dev/mapper/pocitac-koren $ sudo btrfs fi df / [sudo] heslo pro root: Data, single: total=757.00GiB, used=755.49GiB System, single: total=32.00MiB, used=112.00KiB Metadata, single: total=3.00GiB, used=2.57GiB GlobalReserve, single: total=512.00MiB, used=0.00B The numbers keep changing, so it's not super up-to-date, but I hope the problem is obvious. Fix is possible by using 'sudo btrfs balance start /' - it usually enlarges limit for Metadata. I never had such issue on older system (updated to the same TW snapshot), but I keep having it regularly on new installs. Is it some known bug with Btrfs, or should I report it? Yours, V.
That's a known issue: btrfs reports the wrong numbers in statfs(2). Most recent bug report at the upstream GNU coreutils ML: https://lists.gnu.org/r/bug-coreutils/2020-02/msg00011.html I don't know if there are bug reports against btrfs, though. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
10.02.2020 02:30, Bernhard Voelker пишет:
On 2020-02-09 20:09, Vojtěch Zeisek wrote:
Hi, I installed twice new TW system (once after replacement of disk) using TW snapshot 20200205 image. Installation went fine, but on running system I repeatedly run into problems with 'df -h' showing no space available, but 'sudo btrfs fi show /' correctly showing plenty of space. The answer is in 'sudo btrfs fi df /' showing I'm (nearly) running out of space of Metadata: $ df -h Souborový systém Velikost Užito Volno Uži% Připojeno do devtmpfs 12G 0 12G 0% /dev tmpfs 12G 111M 12G 1% /dev/shm tmpfs 12G 1,7M 12G 1% /run tmpfs 12G 0 12G 0% /sys/fs/cgroup /dev/mapper/pocitac-koren 3,5T 759G 0 100% / /dev/mapper/pocitac-koren 3,5T 759G 0 100% /.snapshots /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/x86_64-efi /dev/mapper/pocitac-koren 3,5T 759G 0 100% /opt /dev/mapper/pocitac-koren 3,5T 759G 0 100% /boot/grub2/i386-pc /dev/mapper/pocitac-koren 3,5T 759G 0 100% /root /dev/mapper/pocitac-koren 3,5T 759G 0 100% /usr/local /dev/mapper/pocitac-koren 3,5T 759G 0 100% /tmp /dev/mapper/pocitac-koren 3,5T 759G 0 100% /var /dev/mapper/pocitac-koren 3,5T 759G 0 100% /home /dev/mapper/pocitac-koren 3,5T 759G 0 100% /srv /dev/sda1 300M 8,1M 292M 3% /boot/efi tmpfs 2,4G 0 2,4G 0% /run/user/65534 tmpfs 2,4G 16K 2,4G 1% /run/user/1000 $ sudo btrfs fi show / Label: 'korinek' uuid: df8db051-fb0b-4d70-b4cb-3126d757f544 Total devices 1 FS bytes used 758.09GiB devid 1 size 3.48TiB used 760.03GiB path /dev/mapper/pocitac-koren $ sudo btrfs fi df / [sudo] heslo pro root: Data, single: total=757.00GiB, used=755.49GiB System, single: total=32.00MiB, used=112.00KiB Metadata, single: total=3.00GiB, used=2.57GiB GlobalReserve, single: total=512.00MiB, used=0.00B The numbers keep changing, so it's not super up-to-date, but I hope the problem is obvious. Fix is possible by using 'sudo btrfs balance start /' - it usually enlarges limit for Metadata. I never had such issue on older system (updated to the same TW snapshot), but I keep having it regularly on new installs. Is it some known bug with Btrfs, or should I report it? Yours, V.
That's a known issue: btrfs reports the wrong numbers in statfs(2). Most recent bug report at the upstream GNU coreutils ML: https://lists.gnu.org/r/bug-coreutils/2020-02/msg00011.html I don't know if there are bug reports against btrfs, though.
Fixed in kernels 5.6, 5.5.2 and 5.4.18, was not present in earlier kernels (or at least it was much harder to trigger). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-02-10 04:54, Andrei Borzenkov wrote:
That's a known issue: btrfs reports the wrong numbers in statfs(2). Most recent bug report at the upstream GNU coreutils ML: https://lists.gnu.org/r/bug-coreutils/2020-02/msg00011.html I don't know if there are bug reports against btrfs, though.
Fixed in kernels 5.6, 5.5.2 and 5.4.18, was not present in earlier kernels (or at least it was much harder to trigger).
Ah, interesting. Does df(1) now finally see the same values via statfs(2) as shown by "btrfs fi df /"? Or was this change to avoid only extreme miscalculations? Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Andrei Borzenkov -
Bernhard Voelker -
Vojtěch Zeisek