• Contact: tech-kern
• Duration estimate: ~1 month

Implement a fullfs, that is, a filesystem where writes fail with disk full. This is useful for testing applications and tools that often don't react well to this situation because it rarely occurs any more.

The basic fullfs would be just a layerfs layer that you can mount (like nullfs) to get a copy of an existing subtree or volume where writes are rejected with ENOSPC. This is the first thing to get running.

However, for testing it is good to have more than that, so the complete project includes the ability to control the behavior on the fly and a fullfsctl(8) binary that can be used to adjust it.

These are some things (feel free to brainstorm others) that it would be useful for fullfsctl to be able to do:

• Turn on and off the fail state (so for example you can start up a program, let it run for a while, then have the disk appear to fill up under it)
• Arm a "doom counter" that allows the next N writes to succeed and then switches to the fail state (to test what happens if the disk fills partway through a write or save operation)
• Change what error it fails with (ENOSPC is the basic error, but at least EDQUOT and possibly other errors, such as NFS-related ones, are also interesting)

fullfs itself should be implented as a layerfs layer, not a whole filesystem.

fullfsctl should operate via one or more file-system-specific ioctls applied to the root directory of (or perhaps any file on) the fullfs volume.

There are many ways this could be extended further to provide for more general fault injection.