GNOME Bugzilla – Bug 269895
e_fsutils_avail misreports free space, breaking migration from 1.4 to 2.0
Last modified: 2013-09-10 14:03:47 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140744 Above is a report in my downstream bugzilla of free space being misreported; Evolution thinks it has only 1/16th of available space on an NFS mounted home directory (from Solaris 9 server to Fedora Core 3 client) and hence refuses to do a migration even in some cases where there's plenty of disk space. The number reported is highly sensitive to precise settings that the NFS directory is mounted with. Looks to me like the code assumes that f_frsize==f_bsize, and I hope that a simple rewrite will make the code more robust (without breaking anything); I'm about to attach a proposed patch that uses f_bsize instead.
Created attachment 44428 [details] [review] Patch to calculate diskspace from blocksize, rather than fragment size
Created attachment 44469 [details] stat vs statvfs tester
hrm, ok this looks more complicated than it should be. looking at the df source from coreutils, it seems to prefer frsize and only fall back to bsize of frsize is 0. however, also looking at the df sources, configure seems to disable using statvfs when you're running on a glibc based system(!). And then there are 2 different basic statfs alternatives for bsd 4.3 and 4.4. And the linux one doesn't seem to conform exactly to either. From haip on irc: <haip> notzed, on a linux machine with linux directory, the output is: Path bsize bavail frsize <haip> /home/harry/tmp - 4096 1137778 <haip> vfs /home/harry/tmp - 4096 1137778 4096 <haip> on a linux machine with an mounted nfs solaris directory, the output is : <haip> Path bsize bavail frsize <haip> /home/harry/tmp/firstserve - 4096 39748571 <haip> vfs /home/harry/tmp/firstserve - 4096 39748571 4096 so far so good, but: <haip> notzed, it cound not compile on solaris because the defination of statfs is different. After I comment the statfs part, the output is :" <haip> Path bsize bavail frsize <haip> vfs /export/home/haip - 8192 6184225 1024 <haip> df -k output: <haip> : /dev/dsk/c0t0d0s7 13495579 7176399 6184225 54% /export/home so that means we can't use bsize as in the patch, that would be way wrong in this case. I really don't know what to do about this. The bug on the redhat server was worked around/resolved by changing mount options(!), but it doesn't seem that changing mount options should have any effect on statvfs. "curious".
Gnome system monitor and nautilus show the same behaviour. (wrong nfs file system sizes) See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141766
hmm. is this still valid in 2.2?
code hasn't changed, so i guess so. really looks like a kernel/nfs issue to me. it may not be possible to get reliable size information. I knew it was a stupid idea to ever expect we could, but nobody wanted to listen.
Don't know about evolution, because evolution does report filesystem size only in case of error. But gnome system monitor, which behaved the same way in Fedora Core 3, now (FC 4, vers. 2.10.0) reports correct stats. So the error seems to have vanished somehow. Sorry, that I did not answer to grandparent, but by the time I was still with FC 3, and when I upgraded, everything was working and I just forgot.
reassigning to harish; retargetting from very ancient 2.1 milestones to just ancient 2.3 milestones. ;-)
hmm... so can this be marked as obsolete nowadays? any comments? harish?
This bug *is* obsolete and appears to have been outside Evo even earlier. Resolving the bug.