GNOME Bugzilla – Bug 708786
Wrong Disk size with btrfs
Last modified: 2017-04-30 04:05:44 UTC
Created attachment 255723 [details] photo of Disk size 1.4 TB In Gnome settings > Details > Overview, the Disks value is shown as 1.4 TB. The computer has only one internal drive that's 500 GB. LVM thin provisioning is not being used. File system is btrfs. [root@f20s ~]# gvfs-info -f / attributes: filesystem::size: 464519168000 filesystem::free: 459891695616 filesystem::type: btrfs filesystem::used: 3916201984
gnome-shell-3.9.91-1.fc20.x86_64
Just to understand, do you have multiple mount points (maybe bind mounts) for the same partition?
This is probably the same bug as bug 674916. Can you attach `gvfs-mount -li` and `udisksctl dump` please?
(In reply to comment #2) There is one btrfs partition, with three subvolumes (boot, root, home), each of which is mounted. (In reply to comment #3) gvfs-mount -li returns nothing, no error message, just another prompt. [root@f20s ~]# udisksctl dump /org/freedesktop/UDisks2/Manager: org.freedesktop.UDisks2.Manager: Version: 2.1.1 /org/freedesktop/UDisks2/block_devices/sda: org.freedesktop.UDisks2.Block: Configuration: [] CryptoBackingDevice: '/' Device: /dev/sda DeviceNumber: 2048 Drive: '/org/freedesktop/UDisks2/drives/WDC_WD5000BEVT_22ZAT0_WD_WXNX08NY3106' HintAuto: false HintIconName: HintIgnore: false HintName: HintPartitionable: true HintSymbolicIconName: HintSystem: true Id: by-id-ata-WDC_WD5000BEVT-22ZAT0_WD-WXNX08NY3106 IdLabel: IdType: IdUUID: IdUsage: IdVersion: MDRaid: '/' MDRaidMember: '/' PreferredDevice: /dev/sda ReadOnly: false Size: 500107862016 Symlinks: /dev/disk/by-id/ata-WDC_WD5000BEVT-22ZAT0_WD-WXNX08NY3106 /dev/disk/by-id/wwn-0x50014ee2ace3e31e org.freedesktop.UDisks2.PartitionTable: Type: gpt /org/freedesktop/UDisks2/block_devices/sda1: org.freedesktop.UDisks2.Block: Configuration: [] CryptoBackingDevice: '/' Device: /dev/sda1 DeviceNumber: 2049 Drive: '/org/freedesktop/UDisks2/drives/WDC_WD5000BEVT_22ZAT0_WD_WXNX08NY3106' HintAuto: false HintIconName: HintIgnore: true HintName: HintPartitionable: true HintSymbolicIconName:
Created attachment 255852 [details] udiskctl dump Let's try this again with the complete output.
After a reinstall and today's 3.10.0 update, I get the same results in the GUI, 1.4 TB. However: [root@f20s chris]# gvfs-mount -li Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) As the volume is ~468GB, but three subvolumes are mounted, 3x468 is about 1.4TB.
Right, that's the thing, we enumerate all mount points and query the filesystem size for each of those. I guess statvfs() returns the partition size instead of subvolume size in that case.
Subvolumes are like folders in this respect, they don't have a size. I'm now really confused about what information Disk is conveying, and what useful storage information the Details UI should convey. Currently it shows the total combined size of partitions. That is not described by the word disk or Disk. I think that's a problem. If I were using LVM across two disks, does the value for Disk comprise the total space available on all LV's? If so that's a problem because again the word is Disk. Singular. And with LVM virtual size LVs coming, I think it's really misleading to show a Disk value as being much much larger than any physical disk can be. It could report Disk as 1EB. I don't see the purpose in doing that. Is physical disk information useful, like processor information is useful? If so report make/model/size. It's easy to determine, and file system inspecific.
Disk size is not a hard to understand concept. The panel is not meant to handle complicated storage configurations like the ones you are describing. If there is no meaningful size we can report, we should probably just say 'unknown'.
Right. The disk in question is 500GB so that's what should be reported. It doesn't matter what partitions there are or what file systems are being used, the disk is 500GB. The other option is 466GB, but I think that's less helpful than matching the label on the disk. In other common scenarios such as dual boot with ext4 used for linux, the value reported for Disk right now makes no sense. I think the panel behavior needs to go for the simplest and most consistent behavior.
Disk is supposed to be the combined size of all the internal disks, except that there's no good way to determine that, especially when using btrfs subvolumes.
Disk is singular, and it's a physical thing. I wouldn't expect its value to represent multiple devices, either physical or virtual. Disk≠the combined size of partitions or LVs either. What's useful information in the context of Details to convey to average Joe User? Everything else it reports is extremely literal. I don't see why Disk information alone needs to be made so non-literal. Pick a disk, display its make/model/size. Disk: Unknown would be really horrible UI and UX. My response to seeing that would be, "you're the operating system, reading and writing MY information to an unknown disk? Really?" If it comes down to unknown, simply do not display the field at all.
(In reply to comment #11) > Disk is supposed to be the combined size of all the internal disks, except that > there's no good way to determine that, especially when using btrfs subvolumes. This is my disk with two subvolumes on a btrfs partition (and swap on sda3): bash-4.2$ findmnt -eo+SIZE --fstab TARGET SOURCE FSTYPE OPTIONS SIZE / /dev/sda4 btrfs subvol=root,compress=lzo 293,7G /boot /dev/sda2 ext4 noauto,comment=systemd.automount 476,2M /home /dev/sda4 btrfs subvol=home,compress=lzo 293,7G and in "gnome-control-center info" the disk size is 631,2 GB. I believe that the most appropriate method to get information about the disk space is the command "lsbkl -f -o+SIZE". With this command, the size of a btrfs partition is interpreted correctly without overestimation due to subvolumes. But we must exclude swap partitions, partition without filesystem (such as cdrom or BIOS Boot partition in a GPT formatted disk), and ... (what ever else?). Since this command can filter the results based only on the major device number (and not on the filesystem), I think the easiest way is to observe the mount point in order to filter with "grep /": bash-4.2$ lsblk -f -o+SIZE NAME FSTYPE LABEL UUID MOUNTPOINT SIZE sda 298,1G ├─sda1 1M ├─sda2 ext4 2859420c-0edb-4271-ba6f-3a092beaec40 /boot 500M ├─sda3 swap f63b3ccb-dc69-4e99-aa89-308af547ab6e [SWAP] 3,9G └─sda4 btrfs fedora edfb8696-53d5-4205-b48d-6556d50cc825 /home 293,7G sr0 1024M ... or in key=value output bash-4.2$ lsblk -Pf -o SIZE,MOUNTPOINT | grep 'MOUNTPOINT="/' SIZE="500M" MOUNTPOINT="/boot" SIZE="293,7G" MOUNTPOINT="/home" ... or in bytes bash-4.2$ lsblk -bPf -o SIZE,MOUNTPOINT | grep 'MOUNTPOINT="/' SIZE="524288000" MOUNTPOINT="/boot" SIZE="315368669184" MOUNTPOINT="/home"
I thought lsblk could detect even the unmounted partitions found in fstab with the noauto option but I was wrong (I did not realize that /boot was mounted). It does not add any information to "gvfs-info -f /".
*** Bug 741408 has been marked as a duplicate of this bug. ***
*** Bug 674916 has been marked as a duplicate of this bug. ***
Tentatively reassigning to gvfs to get btrfs support.
(In reply to comment #17) > Tentatively reassigning to gvfs to get btrfs support. We don't have proper btrfs support in udisks either (on TODO list for a long time). But looking at the dump from comment 5, at least the information reported are consistent. (In reply to comment #6) > [root@f20s chris]# gvfs-mount -li > Error creating proxy: The connection is closed (g-io-error-quark, 18) Uhm, that looks like a segfault, anything in dmesg? This is probably because of running gvfs-mount as root while the rest of gvfs daemons are on different session bus. We shouldn't fail like this however.
(In reply to comment #18) > (In reply to comment #6) > > [root@f20s chris]# gvfs-mount -li > > Error creating proxy: The connection is closed (g-io-error-quark, 18) > > Uhm, that looks like a segfault, anything in dmesg? This is probably because of > running gvfs-mount as root while the rest of gvfs daemons are on different > session bus. We shouldn't fail like this however. This is being handled in bug 741471. Strangely, gvfs-mount -li as root is entirely silent for me.
Setting see also for a udisks2 + Btrfs bug, which then manifests in Nautilus with no way out for the user (one volume appears as two devices, one of which is automounted and then can't be unmounted).
This is still a bug in Fedora 22. gnome-shell-3.15.92-2.fc22.x86_64 Details > Disk 155.9 GB $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda5 37G 4.7G 32G 14% / /dev/sda5 37G 4.7G 32G 14% /usr /dev/sda5 37G 4.7G 32G 14% /boot /dev/sda5 37G 4.7G 32G 14% /home
I'm seeing 0B reported in Gnome settings > Details > Overview on PC-BSD 10.2 (Gnome 3.16) Shall I raise a separate bug? This does seem similar, except that the file system is zfs. Seems that it might have similar issues as btrfs.
Separate bug is not needed. As far as I know brtfs and zfs are based on same concepts, so this is basically the same problem. Though I am not sure what needs to be done in gvfs in order to fix this bug. The "wrong size" is determined as sum of sizes of unix mounts obtained from statfs. So it seems that gvfs is not included in this process at all...
(In reply to Ondrej Holy from comment #23) > Separate bug is not needed. As far as I know brtfs and zfs are based on same > concepts, so this is basically the same problem. Yes, similar concepts, but disk space is over-reported for btrfs, and massively under-reported for zfs. But if gvfs is not involved, should the bugs be raised on the components where they become apparent, and let the maintainers decide where the fix goes? Best Rgds.
I do think that g-s-d should check free space per device path and not per mount path. Similarly for g-c-c. This should fix the multiple warnings issue and wrong total size info at least for some filesystem types (i.e. BTRFS). I have no idea, how ZFS works and what is wrong with it, but we can probably ignore such obscure filesystem types in g-s-d / g-c-c if the previous suggestion doesn't help...
Created attachment 346638 [details] [review] info: Fix total disc size for btrfs subvolumes Total disc size may be wrong if something like btrfs subvolumes are used. Do not count multiple mounts with same device_path, because it is probably something like btrfs subvolume. Use only the first one in order to count the real size.
Created attachment 346639 [details] [review] housekeeping: Ignore GPFS mounts GPFS mounts cause false low free space alerts, let's ignore them. https://bugzilla.redhat.com/show_bug.cgi?id=1392260
(In reply to Matthew Harrison from comment #24) > (In reply to Ondrej Holy from comment #23) > > Separate bug is not needed. As far as I know brtfs and zfs are based on same > > concepts, so this is basically the same problem. > > Yes, similar concepts, but disk space is over-reported for btrfs, and > massively under-reported for zfs. It is under-reported, because zfs mounts are ignored, but don't ask me why, I don't know zfs. It is hard to support all existing filesystems, especially those obscure: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/housekeeping/gsd-disk-space-helper.c#n79
Created attachment 350728 [details] [review] info: Fix total disc size for btrfs subvolumes Total disc size may be wrong if something like btrfs subvolumes are used. Do not count multiple mounts with same device_path, because it is probably something like btrfs subvolume. Use only the first one in order to count the real size.
Comment on attachment 350728 [details] [review] info: Fix total disc size for btrfs subvolumes Attachment 350728 [details] pushed as b619f7c - info: Fix total disc size for btrfs subvolumes
(In reply to Ondrej Holy from comment #27) > Created attachment 346639 [details] [review] [review] > housekeeping: Ignore GPFS mounts > > GPFS mounts cause false low free space alerts, let's ignore them. > > https://bugzilla.redhat.com/show_bug.cgi?id=1392260 And updated in g-c-c.
*** Bug 768170 has been marked as a duplicate of this bug. ***