df -a contradicts Disk Usage Analyzer.

[emilschwab]

I am using Ubuntu 9.04. I installed Ubuntu 8.10 with Wubi and upgraded to 9.04. I typed df -a in the terminal and I got 13 GB of my root directory and 143 GB at my master Windows. Disk usage analyzer says: filesystem capacity 294 GB.

My HDD total capacity is 160 GB. Please see the screenshot of Disk Analyzer. (I have Intel Pentium 4).

 In the terminal:

 Filesystem 1K-blocks Used Available Use% Mounted on
/host/ubuntu/disks/root.disk
                      13457172 5233116 7540464 41% /
tmpfs 506112 0 506112 0% /lib/init/rw
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
varrun 506112 108 506004 1% /var/run
varlock 506112 0 506112 0% /var/lock
udev 506112 148 505964 1% /dev
tmpfs 506112 136 505976 1% /dev/shm
devpts 0 0 0 - /dev/pts
/dev/sda5 147902388 78323520 69578868 53% /host
fusectl 0 0 0 - /sys/fs/fuse/connections
lrm 506112 2760 503352 1% /lib/modules/2.6.28-11-generic/volatile
/host/ubuntu/disks/boot
                     147902388 78323520 69578868 53% /boot
securityfs 0 0 0 - /sys/kernel/security
binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc
gvfs-fuse-daemon 0 0 0 - /home/xyz/.gvfs

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/yelp
NonfreeKernelModules: nvidia
Package: yelp 2.25.1-0ubuntu5
ProcEnviron:
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: yelp
Uname: Linux 2.6.28-11-generic x86_64

[Brian Murray (brian-murray)]

Looking at the attachments in this bug report, I noticed that "Disk usage analyzer screenshot" was flagged as a patch. A patch contains changes to an Ubuntu package that will resolve a bug, since this was not one I've unchecked the patch flag for it. In the future keep in mind the definition of a patch. You can learn more about what qualifies as a patch at https://wiki.ubuntu.com/Bugs/Patches. Thanks!

[Onlyodin (ubuntu-xsnet)]

I am having a similar issue with 9.04 AMD64 and Disk Usage Analyser.

When I do a 'Scan Filesystem' from Disk Usage Analyser it shows "Total filesystem capacity:"... which are accurate and match df -h, but the folder breakdown is vastly different from the above - Whilst the real disk usage is over 320Gb, the total in the 'breakdown' list shows a total of 37Gb.

[Antono Vasiljev (antono)]

Baobab reports wrong disk free/used space report. See attatched screenshot with df -h and baobab.

I'am on jaunty.

cat /etc/debian_version
5.0

[TenLeftFingers (tenleftfingers)]

I'm having the same problem with Baobab 2.28.1 on Ubuntu 9.10.

Nautilus reports 4.3GB available and 'df -h' command report 4.4GB available. Boabab says I have 5.7GB available.

The reason for this is in confusion over the terms 'free space' and 'available space'.

If you run System Monitor and click the File Systems tab, I can see the information:

Free Space: 5.7GB
Available: 4.3GB (As opposed to the 4.4GB reported by 'df -h'

So it seems that the problem isn't specific to one package but maybe just a lack of co-ordination on how to report disk usage among all these applications. I don't know how to report this problem though, as there doesn't seem to be a specifiic package to report it to. Maybe the desktop experience team?

[tc (something-bz)]

Let's extract the important numbers from #2's Screenshot.png: 294.9 total, 154.4 used, 140.6 free

Looking at the output of df, I can see *three* things which are non-tmpfs/procfs/sysfs/devfs:
 Filesystem 1K-blocks Used Available Use% Mounted on
/host/ubuntu/disks/root.disk
                      13457172 5233116 7540464 41% /
/dev/sda5 147902388 78323520 69578868 53% /host
/host/ubuntu/disks/boot
                     147902388 78323520 69578868 53% /boot

If you sum these, you get 309261948 (294.935 GB), 161880156 (154.381 GB), 146698200 (139.902 GB). The discrepancy in "free" space is because some filesystems (ext2/3) typically reserve some space for use by root so that some things will keep working even if a normal user manages to fill the filesystem. / is "missing" 683592 K (about 5.08%).

From the sizes, it looks like /dev/sda5 (/host) and /host/ubuntu/disks/boot (/boot) are actually the same filesystem. I'm not sure how that works, but clearly baobab isn't detecting that they're duplicates.

I'm thinking that they should be marked as duplicates if they have the same device number; anything more and it gets silly.

[Gibby82 (junk-gibson)]

Looks like I have the same issue.

administrator@delta-one:~$ df -a
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 96122052 3994724 87244516 5% /
proc 0 0 0 - /proc
none 0 0 0 - /sys
none 0 0 0 - /sys/fs/fuse/connections
none 0 0 0 - /sys/kernel/debug
none 0 0 0 - /sys/kernel/security
none 2023788 364 2023424 1% /dev
none 0 0 0 - /dev/pts
none 2028548 3380 2025168 1% /dev/shm
none 2028548 1528 2027020 1% /var/run
none 2028548 0 2028548 0% /var/lock
none 2028548 0 2028548 0% /lib/init/rw
/dev/sda1 188403 55704 122971 32% /boot
/dev/sda4 205581032 2488448 192649628 2% /home
/dev/md0 1922867888 716975668 1108216144 40% /media/storage
binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc
gvfs-fuse-daemon 0 0 0 - /home/administrator/.gvfs

[Karl-Philipp Richter (krichter722)]

This issue persists in version 3.8.2 on Ubuntu 13.10. This was avoided once when an option to forbid filesystem border crossing was introduced which has been removed again later. This option suppressed the malious behavior to include files which are bound or mounted.
In order to fix rather than suppress the issue, I'd suggest to let baobab check the st_dev property of the stat struct (see http://linux.die.net/man/2/stat).

[Rolf Leggewie (r0lf)]

From what I can tell, this works fine for me in trusty, even when the same device is mounted more than once (which as per #7 seems to be the root cause of this problem)