I like stress testing software (to be honest: no, not really). Yesterday I debugged a problem regarding zsh history writing on ENOSPC. Usually I use the grml Linux live-cd for stress testing (often running inside Qemu, Virtbox, VMware,…) like in:
dd if=/dev/zero of=/tmp/home.lo count=1000 losetup /dev/loop1 /tmp/home.lo mkfs.ext3 /dev/loop1 mount /dev/loop1 /home mkdir /home/grml chown grml: /home/grml
Now after restarting the shell session of user grml I can play with ‘No space left on device’ situations. (Notice: I adjust the count=… according to what type of application I want to test.)
Too many applications don’t really cope with the ENOSPC situation. Firefox for example is very funny, depending on the situation it either just segfaults when trying to start up, or decides to not start up at all and just exits with ‘1’. See the relevant strace output:
mkdir("/home", 0700) = -1 EEXIST (File exists) access("/home", F_OK) = 0 mkdir("/home/grml", 0700) = -1 EEXIST (File exists) access("/home/grml", F_OK) = 0 mkdir("/home/grml/.mozilla", 0700) = -1 ENOSPC (No space left on device) access("/home/grml/.mozilla", F_OK) = -1 ENOENT (No such file or directory) exit_group(1) = ?
Opera also just exits when already running and receiving an ENOSPC – I encountered data loss (for example the transfer history got lost) more than once. Very "funny" to see how applications like dillo, joe, wireshark,… behave in the ENOSPC situation. Not.
Oh, your application handles ENOSPC just fine? Then continue testing with read-only filesystem, using NFS, removing files randomly,…