Which filesystem / filesystem option to use for /tmp partition

From my experience running an encrypted reiserfs with private information you should not put that on an journalling filesystem like ext3. I switched back from ext3 to having the file on an ext2 partition after I had to restore from a backup.

Over the years ( I have had this file for 5 years ), I had to run recovery several times, and when hosted on ext3 this was the only time reiserfsck could not recover. I think that was because ext3 did a recover which confused the internals of the encrypted disk.

I never tried a non-journal filesystem on a journal filesystem (e.g. encrypted ext2 file on reiserfs) for me the important (i.e. encrypted data should be journalled).

I am still running reiserfs, never used ext4 for this (but I am considering btrfs, just need to check some time if that is stable enough)

If you put your homedirectory on there, be prepared that this feels a bit sluggish, I don't think any finetuning with parameters could have helped that, and I don't think the ext4 ones will influence things much, given that encryption is a performance penalty hit in all directions.

All three data journaling modes should leave the filesystem itself fully intact after a power failure. So it should always mount without errors. The difference is only in the data in your files; data=writeback mode may leave stale data (i.e., what was stored in the disk sectors before the writes your app did). data=ordered and data=journaled should not do this.

Most likely what you're seeing is that I/O barriers aren't working on your setup. First, make sure you're not mounting with barrier=0/nobarrier. That boosts performance, but will cause corruption on power failure.

If I/O barriers are on, it's also possible you're passing through a storage layer that doesn't support them. On older releases, LVM didn't and various mdraid levels didn't. (This was fixed in Linux 2.6.33; so only if you're running Lucid still.)

Finally, it's possible your disks are telling lies. Disks have write caches. Especially with NCQ, they're supposed to only tell the OS they've written data when they've actually done so, but they've been known to tell the OS its written when its only in the disk's write cache. Increases performance. At least as long as the power stays on. You can try disabling the write cache on the disks, though you'll take a performance hit for this.

Note also that flash-memory disks have a lot of work to do under the hood, and many of them don't handle power failure well. (For example, wear leveling sometimes requires that a full flash block of data be moved. If the power fails in the middle, bad things happen on some flash disks.)

Finally... have you considered an UPS?