After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332764 - "disk full" warning logic is broken
"disk full" warning logic is broken
Status: RESOLVED FIXED
Product: gnome-volume-manager
Classification: Deprecated
Component: general
1.5.x
Other All
: Normal normal
: ---
Assigned To: Rodney Dawes
Gnome volume manager maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-27 17:35 UTC by Dooglus
Modified: 2006-03-10 18:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch to fix disk space notification issues (4.62 KB, patch)
2006-03-09 22:21 UTC, Rodney Dawes
committed Details | Review

Description Dooglus 2006-02-27 17:35:52 UTC
Please describe the problem:
1.  When gnome-volume-manager starts up, it warns about volumes which are
between 80% and 97.5% full.  If a volume is >97.5% full no warning is generated.
 this is because of this code in manager.c:

		else if ((free_space - info->last_pct) < config.percent_freed)
			info->notified = TRUE;

last_pct is initialised to 0.0, so whenever free_space < 0.05, notified is set
to TRUE which inhibits the warning.

2.  If I free a lot of disk space at once, the warning appears.  I imagine that
the intent was for the warning to appear when a lot of space was used quickly,
rather than when it is freed.  This is because of this code in manager.c:

		if ((free_space - info->last_pct) > config.percent_used)
			info->notified = FALSE;

The two terms in the subtraction need to be in the opposite order.  The amount
of space used since the last time we looked is (info->last_pct - free_space),
not the other way around.

3.  If I fill up the disk slowly, the warning will never be triggered.  The
warning is triggered only if I use more than 2.5% of the space between calls of
gvm_statfs_check_space().  Note that
		info->last_pct = free_space;
gets run every time we check the space, whether we display a warning or not.  I
suspect that the intention is for last_pct to be the percent free *when we last
displayed a warning*.  That way the warning will be displayed whether we fill
the disk quickly or slowly.

4.  I can't see what the purpose of this code is:

		else if ((free_space - info->last_pct) < config.percent_freed)
			info->notified = TRUE;

It is inhibiting the display of a warning when the amount of space freed is less
than 5%.  Perhaps the < should be a >?  But in any case if we are freeing space
rather than using it then there's nothing to trigger the warning anyway.

A few scattered comments in the code would help.  If I knew what the code was
trying to achieve then I could fix it.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Rodney Dawes 2006-03-09 22:21:24 UTC
Created attachment 61007 [details] [review]
Patch to fix disk space notification issues

This patch should take care of the issues presented here. Please let me know how it works for you. Thanks.
Comment 2 Dooglus 2006-03-09 23:03:51 UTC
I don't see how your patch addresses point #3, "If I fill up the disk slowly, the warning will never be triggered".

I would hope to see some kind of warning that the disk was getting full no matter how slowly I was filling it up.  Currently I have to write a whole gigabyte between successive calls of the function for the alert to be triggered (assuming a 100Gb disk).
Comment 3 Rodney Dawes 2006-03-10 01:01:43 UTC
Do you have a suggestion for a percentage value that would work? The entire point of the code is to avoid popping up the dialog constantly, because syslog keeps writing to disk and such. 1GB is a lot of data, sure. But what would you expect it to do for a 128MB flash card? What if you have 1TB of storage? There's no way that we can cover *all* of these cases with one value. The sizes of things that a user might plug into their system is quite varied, so we need some value that's somewhat reasonable and handles the lower end well. I think that on average, 1% is a reasonable threshold for change in disk usage to warn again, and 5% is reasonable for the initial warning. I originally was thinking 20%, but 20% really is too larger for internal storage devices in general. So this does address this issue to an extent, but not to the extent that you deem reasonable for your machine(s) (which is why there's a gconf key to change it).  The default needs to be a reasonable approximation of what 100K+ machines that this could be deployed to, might have for internal storage, and what users might be plugging in to those machines as external storage devices (such as iPods and cameras).
Comment 4 Dooglus 2006-03-10 01:41:39 UTC
My point was that it shouldn't matter how fast I fill up the disk.  I
should see warnings whether the disk becomes 95% full over a period of
5 years of slow accumulation or over a frantic 2 minutes of activity.
A 100% full disk is bad news whether it happens suddently or
gradually, so why is there a speed element in the algorithm used?

It might be better to issue a warning every time another 5% of
capacity (over 80%) is used, without resetting the counter each time
the function is called.  So in the case of a very slow filling of the
disk, I'll get a warning when it hits 80%, then 10 hours later I'll
see another warning when it gets to 85%, and so on.

The currently code won't give me any warnings at all, not even when
the last free byte is used, which isn't a good behaviour for code
which exists purely to warn about disks filling up.
Comment 5 Jeffrey Stedfast 2006-03-10 18:48:09 UTC
I've committed the patch to CVS
Comment 6 Jeffrey Stedfast 2006-03-10 18:54:06 UTC
this should be fixed now, will be making a new release shortly