Ubuntu Wiki

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.

• Launchpad entry: none yet

• Packages affected:

Summary

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.

Rationale

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 https://bugs.launchpad.net/distros/ubuntu/+source/pkgsel/+bug/9459, https://bugs.launchpad.net/distros/ubuntu/+source/evolution/+bug/12906.

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.

• Bob run A, it run nicely for a while, but suddenly a message appears saying that the program is near to miss some disk space and saving (if available) should be done, and some disk cleaning be done before continuing, or the program may behave erroneously.
• Bob come to run B, but a message appears saying that the program did request to open for writing on /dev/hda1, but only N megabytes is free, so the request to open file was refused by the operating system.
• Bob try to run P, but get the same message as when trying to run B above.
• Marc knows that P do know how to handle nicely low disk space, but was written before this specification was written. He have used the GUI to deactivate legacy handling of low disk space on P. He run P, and is able to use P finely, treating low disk space problems the way P was design to handle them (whatever it is).
• Bob come to run X (a new program). But a window appears saying that X need 40 Mb minimum on /dev/hda2, but only 25Mb is still free on it, so that X can not be started until some cleaning have been done. A button suggest a program to be started, that will propose some way to make more space free on /dev/hda2.
• Bob come to run Y, but a window appears saying that Y typically need 20Mb, but only 17Mb is free on disk, and he have the choice of running Y, or abort it.

Scope

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 https://bugs.launchpad.net/distros/ubuntu/+source/gnome-volume-manager/+bug/33967

Design

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

Implementation

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion

CategorySpec