Comment 4 for bug 561129

This is a regression in Oneiric and/or the 3.0.0 kernel. This doesn't happen using the 2.6.38 kernel from Natty. Here's the sequence of events:

1. Boot 3.0.0 Oneiric kernel. ~1.9 GB free space.
2. Log in to user with ecryptfs home.
3. Do random ops in the filesystem. Free space remains the same.
4. $(du -hcs ~/.mozilla/firefox) ~= 400 MB.
5. Start Firefox. After it loads, free space is down to ~300 MB (1.6 GB less), but ~/.mozilla/firefox is still ~400MB.
6. Free space continues to decrease. A minute later, it's at 0 bytes free. ~/.mozilla/firefox is still ~400MB.
(6a. plasma-desktop hangs with 0 bytes free space [another regression], have to log out through DBUS call to ksmserver or use SAK, etc)
7. After logging out, free space still at 0 bytes.
8. Reboot into 2.6.38 kernel from Natty (rest of system still Oneiric). Free space is back at ~1.9 GB!
9. Log in to user with ecryptfs home.
10. Do random ops. Free space the same.
11. Start Firefox. After it loads, free space still ~1.9 GB.
12. Use Firefox for a while. Free space still ~1.9 GB.
13. Conclude that there's an ecryptfs bug in 3.0.0 being triggered by Firefox somehow.

I ran $(lsof | grep firefox) while running 3.0.0 and at 0 bytes free and checked with du all the directories Firefox could be writing to (i.e. not /usr/lib, /usr/share, etc), but none were using an abnormal amount of space, certainly nothing adding up to anywhere near 1.9 GB.

I did not note any ecryptfs errors in dmesg before it reached 0 bytes free. I did not run fsck between switching kernels this time. A few days ago I did run fsck several times but always found the fs to be clean in spite of this bug.

It seems strange that upon rebooting the free space is available again. Perhaps it's ecryptfs interacting with ext4 in some way to incorrectly allocate or preallocate space?