Created attachment 1750287 [details] System Monitor's shapshot Description of problem: Please refer to the enclosed snapshots. I have two similarly set up mounts, both are btrfs-raid1 with 2 disks over luks. For one of them /home System Monitor shows correct 'Available' value and calculates correct 'Used%'. For the other /mnt/backup it shows Available=0 and Used=100% which is wrong. Version-Release number of selected component (if applicable): System Monitor 3.38.0 Additional info: Not sure if it is System Monitor's or btrfs issue.
Created attachment 1750288 [details] lsblk's snapshot
I don't use btrfs for myself. Can you please open an upstream report https://github.com/mate-desktop/mate-system-monitor
https://github.com/mate-desktop/mate-system-monitor/issues/207 Done
Wrong package , this isn't a mate application.
For the file system showing 100% used, can you provide the following: btrfs fi us /mnt/backup cd /sys/fs/btrfs/$FSUUID/allocation/ grep -R . Where $FSUUID is found by lsblk -f or blkid for the file system mounted at /mnt/backup
And also: df -h /mnt/backup stat -f /mnt/backup
Sure: # btrfs fi us /mnt/backup Overall: Device size: 1.82TiB Device allocated: 1.19TiB Device unallocated: 648.98GiB Device missing: 0.00B Used: 1.18TiB Free (estimated): 325.37GiB (min: 325.37GiB) Free (statfs, df): 325.37GiB Data ratio: 2.00 Metadata ratio: 2.00 Global reserve: 512.00MiB (used: 0.00B) Multiple profiles: no Data,RAID1: Size:606.00GiB, Used:605.12GiB (99.85%) /dev/mapper/backup_1of2 606.00GiB /dev/mapper/backup_2of2 606.00GiB Metadata,RAID1: Size:1.00GiB, Used:881.84MiB (86.12%) /dev/mapper/backup_1of2 1.00GiB /dev/mapper/backup_2of2 1.00GiB System,RAID1: Size:8.00MiB, Used:112.00KiB (1.37%) /dev/mapper/backup_1of2 8.00MiB /dev/mapper/backup_2of2 8.00MiB Unallocated: /dev/mapper/backup_1of2 324.49GiB /dev/mapper/backup_2of2 324.49GiB # grep -R . metadata/raid1/used_bytes:924680192 metadata/raid1/total_bytes:1073741824 metadata/disk_used:1849360384 metadata/bytes_pinned:0 metadata/bytes_used:924680192 metadata/total_bytes_pinned:0 metadata/disk_total:2147483648 metadata/total_bytes:1073741824 metadata/bytes_reserved:0 metadata/bytes_readonly:131072 metadata/bytes_may_use:536870912 metadata/flags:4 system/raid1/used_bytes:114688 system/raid1/total_bytes:8388608 system/disk_used:229376 system/bytes_pinned:0 system/bytes_used:114688 system/total_bytes_pinned:0 system/disk_total:16777216 system/total_bytes:8388608 system/bytes_reserved:0 system/bytes_readonly:0 system/bytes_may_use:0 system/flags:2 global_rsv_reserved:536870912 data/raid1/used_bytes:649743667200 data/raid1/total_bytes:650687545344 data/disk_used:1299487334400 data/bytes_pinned:0 data/bytes_used:649743667200 data/total_bytes_pinned:0 data/disk_total:1301375090688 data/total_bytes:650687545344 data/bytes_reserved:0 data/bytes_readonly:131072 data/bytes_may_use:0 data/flags:1 global_rsv_size:536870912 # df -h /mnt/backup Filesystem Size Used Avail Use% Mounted on /dev/mapper/backup_1of2 932G 607G 326G 66% /mnt/backup # stat -f /mnt/backup File: "/mnt/backup" ID: 2fe2db6ba3d4cdee Namelen: 255 Type: btrfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 244186550 Free: 85200873 Available: 85293271 Inodes: Total: 0 Free: 0 Thank you very much.
Also corrected link: https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/issues/174
OK good, there's nothing wrong or unusual with this Btrfs file system. However, I'm not sure how System Monitor determines any of the values in its fields, in particular Available (and thus the percentage). It's obviously confused, but I can't tell why. I think for now, we can focus on the upstream bug.
Indeed. Its a relieve that Btrfs is OK. Bug in System Monitor is more of a convenience - hopefully resolved sooner then later. Thank you.
I was able to reproduce the bug. I rebuild the btrfs-raid1 over luks. All looked normal until i copied into this directory the SomeBigImage.iso file. System monitor Usage% jumped to 100% although I have free space on the disk. I reported that upstream. Hope it helps.
Few further observation are added here: https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/issues/174
I have this issue as well but not with raid1. https://gitlab.gnome.org/GNOME/libgtop/-/issues/55 This is when I was converting my existing system to use btrfs transparent compression. All utilities like df -H, baobab (disk usage analyzer), compsize were fine but its some issue in libgtop. Also note that I also have LUKS enabled. that can also be the cause.
Some others user had this issue on Fedora 34 fresh installation on Gnome Boxes with automatic partitioning. I am just fine as this is just a cosmetic issue but this must be solved anyway.
I can't reproduce on a clean install of Fedora 34 Workstation edition, automatic partitioning with encryption enabled. (Or Fedora 33. Or with or without compression.) One of the upstream reports, the reporter closed the bug because it stopped manifesting. Seems hard to reproduce, but also transient. I'm not sure what information to gather from system-monitor if we do find a reproducer. Maybe 'strace df' should be included with it for comparison?
Created attachment 1772761 [details] System Monitor shows wrong Available size
I am observing the same misbehavior of the System Monitor on another pair of luks-btrfs-raid1. All was fine until disks filled to about 500G . Then suddenly 'Available' jumped to 0 although I have plenty of space. There is certainly a problem either in SM or on this combination luks-btrfs-raid1.
Additional info: df reports: Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 32825316 0 32825316 0% /dev tmpfs 32882320 6508 32875812 1% /dev/shm tmpfs 13152928 2412 13150516 1% /run /dev/mapper/rt 942185744 186662748 707592784 21% / /dev/md125 1013688 297476 647504 32% /boot /dev/md124 523944 21000 502944 5% /boot/efi tmpfs 32882320 4448 32877872 1% /tmp /dev/mapper/backup_1of2 976746200 714547788 261638372 74% /mnt/backup /dev/mapper/home_1of2 488370200 264640428 223454388 55% /home /dev/mapper/str_1of2 1953498200 485337044 1468219772 25% /mnt/str tmpfs 6576464 132 6576332 1% /run/user/1000 sudo btrfs filesystem usage /mnt/str Overall: Device size: 3.64TiB Device allocated: 926.02GiB Device unallocated: 2.73TiB Device missing: 0.00B Used: 924.76GiB Free (estimated): 1.37TiB (min: 1.37TiB) Free (statfs, df): 1.37TiB Data ratio: 2.00 Metadata ratio: 2.00 Global reserve: 512.00MiB (used: 0.00B) Multiple profiles: no Data,RAID1: Size:462.00GiB, Used:461.82GiB (99.96%) /dev/mapper/str_1of2 462.00GiB /dev/mapper/str_2of2 462.00GiB Metadata,RAID1: Size:1.00GiB, Used:578.22MiB (56.47%) /dev/mapper/str_1of2 1.00GiB /dev/mapper/str_2of2 1.00GiB System,RAID1: Size:8.00MiB, Used:80.00KiB (0.98%) /dev/mapper/str_1of2 8.00MiB /dev/mapper/str_2of2 8.00MiB Unallocated: /dev/mapper/str_1of2 1.37TiB /dev/mapper/str_2of2 1.37TiB
re: c18, btrfs' own estimator and statfs agree, and system-monitor/libgtop is way off. So I think the bug is there, but we need to hear back from someone more knowledgeable about how to enable system-monitor debugging (would that help?) or who understands the code well enough to just see the bug. I know df uses statfs() and newfstatat() from stracing it. I'm not sure whether and where any btrfs specific code might exist, but probably there?
*** Bug 1992725 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This problem is still present in Fedora 35 Workstation with gnome-system-monitor.x86_64 version 41.0-1. It is transient as described previously, because sometimes everything is reported correctly, and other times not. For example, I'm looking at it right now and seeing that it's reporting one BTRFS partition (in RAID 0, spread over two mechanical disks, with compression) as having 0 bytes available, but another BTRFS partition (single drive, also with compression) as having the correct number of bytes available. Other times I've seen it report the opposite configuration, and other times it reports both as having no bytes available. However, does it make sense to track this bug here? Given the lack of upstream activity on this issue in their tracker, it's likely going to be another one[1] of these bugs that never gets fixed, which would leave this bug here open forever. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1893457
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.