From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Description of problem: When I run evolution for the first time after upgrading to FC3 from FC2, I get an error: "Insufficient disk space for upgrade. Upgrading your data and settings will require upto 1583362 KB of disk space, but you only have 710361 KB available. You will need to make more space available in your home directory before you can continue." My home directory is NFS mounted from a Solaris 9 box. df -k ~: Filesystem 1K-blocks Used Available Use% Mounted on athena:/wrg 43376616 31577080 11365776 74% /wrg Which, as I read it, is 11GB, much more than is necessary. Version-Release number of selected component (if applicable): evolution-2.0.2-3 How reproducible: Always Steps to Reproduce: 1.start evolution 2.observe error 3. Actual Results: saw error message as above Expected Results: migration occurs Additional info:
What are the fragment size and the block size on the NFS filesystem?
rsize, wsize set to 8192 Not sure what you mean by fragment size. Connection is ethernet, MTU is set at 1500.
It appears to be using this code to determine free space (which I believe will be wrong if the fragment size != block size) struct statvfs stfs; if (statvfs(path, &stfs) == -1) return -1; /* Assumes that frsize === power of 2 */ if (stfs.f_frsize >= 1024) return stfs.f_bavail * (stfs.f_frsize / 1024); else return stfs.f_bavail / (1024 / stfs.f_frsize);
Evolution's disk space calculation seems to be wrong by a factor of 16 i.e. it believes you have exactly 1/16th of the space you actually have (as reported by df). Does the NFS mount use version 2 or version 3 of the protocol? (If you cat /proc/mounts, you will see the options for the filesystem, expect to see a "v2" or "v3" in the options). Does the problem go away if you try remounting the NFS filesystem using the other version of the protocol?
Created attachment 107429 [details] Patch to calculate diskspace from blocksize, rather than fragment size
Created attachment 107430 [details] 2nd attempt at using block size, rather than fragment size
As further test, can you run strace df, and look through the output for calls to statfs (or statfs64), and paste the results here
Tried removing the wsize,rsize options in the fstab, and mount. size reported was even less, and mount(1) showed a wsize, rsize of 32K. Tried with a wsize, rsize of 4K, and was able to upgrade settings without error. This shows pretty conclusively what happened. What exactly do you need me to do? I'm AFK until Dec 3.
statfs64("/wrg", 84, {f_type="NFS_SUPER_MAGIC", f_bsize=4096, f_blocks=10844153, f_bfree=3049606, f_bavail=2941165, f_files=5209856, f_ffree=5022281, f_fsid={0, 0}, f_namelen=255, f_frsize=512}) = 0
OK - so the fragment size is 512 bytes, but the block size is 4096, a factor of 8 The existing Evolution code would calc: f_bavail * f_frsize = 1505876480 bytes (1470582.5 KB, or 1.4GB) but df should calc: f_bavail * f_bsize = 12047011840 bytes (11764660 KB, or 11.2GB) Looks like we haven't accounted for an extra factor of 2, for some reason (assuming my calculations are correct...)
I've opened an upstream bug for this here: http://bugzilla.ximian.com/show_bug.cgi?id=69895
This is after a change to rsize,wsize to get this to work. Note that the problem occurred when wsize and rsize were set to 8K, which takes care of the extra factor of two you are seeing. :) with block size at 4K, I was able to complete the upgrade!
Aha - excellent! Thanks for the feedback.
Had the same problem. Workaround was using nfsvers=2 (block size 4k). Filed bug #141766 to libgnome, because this seems to be not only an evolution problem. Gnome system monitor shows the same behaviour.
Nautilus is affected, too.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Upstream bug suggests that this got fixed by FC4. Closing.