Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This specification describe how to make new programs that behave more consistently when lacking or coming close to lack disk space, and how to make existing programs that do not handle lack of disk space to behave better.


Many programmers did not took time to decide how to test and react when their programs come to use a hard disk with low disk space, mostly because their is no easy way to handle this, and because it is perceived as not much likely to happen. Bug #22842 (Many programs misbehave when running out of disk space) have convinced me that a specification should be written, as the way to handle this is not obvious, and discussion is needed. Other bugs related to this spec are,

Use cases

In the following, A and B are two programs that did suppose that low disk space would never happened. P is a program that were design to deal with low disk space, but before this specification was written. X Y and Z, are three programs designed to deal with low disk space, as defined by this specification.


Legacy programs trying to write more than typical filesize, could be outside the scope of this specification. Also, I begin to realize that gnome-volume-manager seems to do almost the same thing, and in fact is said to be annoying about low disk space, see


PaulD: At first I have thought about modifying the kernel to make some test when opening files for writing, and/or writing to them. But I sure not like the idea of having to used some hacked kernel. So using a lowdiskd daemon seems a better idea. As I see it, legacy programs would call a lowdiskwrap wrapper. By example: lowdiskwrap vi /etc/someprog.conf would first call lowdiskd, to ask if it knows about vi. lowdiskd would return some minimal disk space for vi to accept to run, and some typical disk space value for each name/position of parameters that hold a filename. If the program is unknown, some configured default minimal and typical values are returned. If disk free for the disk holding the filename (or for the disk of current directory if program is unknown, or not receiving filenames) is between minimal and typical values, a warning is shown, and the user is asked if he wish to run the program anyway. Then the program (vi) is run with all the parameters received after the name of the program to run (here /etc/someprog.conf). After the program returns, some others checks are done, to ensure that diskspace have not become lower than some trigger level, and some warning is issue if free disk space is under trigger level. Newer programs, do call directly lowdiskd, to make sure estimated needed size is still free on disk, before beginning to write to it. Well, all this is just a suggestion of design. Discussion in first phases of specifications are of course welcome.

* What seems to be lacking is some way to ensure that the disk size requested will be available for a certain time. At the moment, X couuld enquire if n kilobytes of space is available, be told yes, but have A (or indeed P or Y) snaffle it inbetween the time of asking and X actually writing it. There is also the issue of the time necessary to determine how much free space there actually is, which can be significant, especially as a really well-behaved program would ask the question before many writes, and may not be possible with some devices. Finally, the example of vi is interesting: how much disk space does vi need? Answer: it depends on what it's being asked to do! If I change something in a 100M byte file, and want to write the results to a new file, 'quite a lot'. If I just want to look at a small file, 'hardly any'. I wonder if the real answer is to treat A and B's behaviour as a bug and make sure they behave properly - all programs should cope if the stuff they write fails for other reasons (e.g. a physical error causing a write to fail) so why say it's not their bug if they fail for this reason? Ian



Data preservation and migration

Unresolved issues

BoF agenda and discussion


HandleNicelyLowDiskSpace (last edited 2008-08-06 16:15:49 by localhost)