testing out of disk space in linux

Question

I have a program that may be dying when it runs out of disk space writing a certain file, I am not sure if this is the case.

I'd like to run it and see, but my test server is not going to run out of space any time soon. Is there any way I could mock this behavior? It doesn't look like there is any way to set a folder/file size limit in Ubuntu, and getting user quotas set up is going to be a process ( due to getting permissions )

Is there a common way of testing this situation?

I'm running Ubuntu 12.04

Answer 1

1. Create a file of the size you want (here 10MB)

   dd if=/dev/zero of=/home/qdii/test bs=1024 count=10000

2. Make a loopback device out of this file

   losetup -f /home/qdii/test

3. Format that device in the file system you want

   mkfs.ext4 /dev/loopXXX

4. Mount it wherever you want (/mnt/test should exist)

   sudo mount /dev/loopXXX /mnt/test

5. Copy your program on that partition and test

   cp /path/my/program /mnt/test && cd /mnt/test && ./program

---

Substitute /dev/loopXXX with the loop device losetup created, find out with losetup -a .

When done, don't forget to:

• unmount with sudo umount /mnt/test .
• clean up loop devices after use, with losetup -D /dev/loopXXX
• remove the file.

Answer 2

Just use /dev/full, it will raise the ENOSPC error when you try to write to it:

$ echo "Hello world" > /dev/full
bash: echo: write error: No space left on device

Answer 3

Another possibility would be to reduce the appropriate limit with setrlimit(2) syscall with RLIMIT_FSIZE or with the bash ulimit builtin (using -f). Then write(2) would fail with EFBIG

And you could also set some quotas on some appropriate file system, so write(2) fails with EDQOT.

If you want the real ENOSPC error to write(2) you probably need a loopback file system as answered by qdii.

BTW, I don't really know how to "emulate" the EIO error (maybe with some FUSE filesystem?).

Many programs handle write(2) errors (and nearly all should). But I don't know many programs which handle very differently the various errors possible with write(2). Most programs handle all write(2) errors the same way.

^{However, you might need to handle EINTR and EWOULDBLOCK errors differently: these are recoverable errors, and you usually redo the write(2) at some later time.}