Well according to the manual it does work in ext4 except in data=journal mode, so most Linux users should be alright then, no?

If you're using a solid state disk, even FAT or ext2 won't make shred useful.  SSD's do lots of stuff underneath the filesystem to speed things up and for wear leveling, so even if the filesystem things it is overwriting the file it probably isn't.  (On the bright side, many SSD's are agressive about reclaiming deleted blocks, so if your OS deletes it instead of moving it to a trash directory, it will get overwritten quickly.)

Since data=ordered is the default then what's the problem?


Don't know much about the new feature being worked on, will it basically make manual GPG or TrueCrypt solutions obsolete or will they still be superior?


As far as I know, with any solution you'll have to temporarily have the wallet unencrypted when you want to use it. I think the main issue with TrueCrypt was the in-memory password storage.

http://en.wikipedia.org/wiki/Truecrypt#Passwords_stored_in_memory

Not anymore. As the flash process shrinks, longevity (number of erase cycles) drops. This drives controller manufacturers to ever more lazy trim command handling (and what you are probably talking about is garbage collection, which has to be filesystem aware). The currently most popular controllers (Sandforce 12xx and 22xx series) do not have active GC and also employ compression, meaning there is a lot more actual free space so trims are executed even lazier. Active GC depends on filesystem bitmap snooping, which usually excludes most other filesystems besides NTFS.

Lazy trim handling means that when you shred LBA 500 to 1000, the controller remaps these to a different flash region from the fresh overprovisioning pool, then notes the old physical location in its internal bitmap. If your SSD is brand new, it will never delete anything until you have written all flash at least once, at which point it will clean out as much as needed for the OP pool, i.e. your data may stick around for a very long time. For wear leveling purposes it might even not erase that particular flash region until a multiple of the whole device's capacity has been written. Increase that by another factor of 2 to 3 due to compression.

Also, ATA trim commands do not propagate through most current RAID controllers. And many systems do not support trim altogether (Windows XP, MacOS 10.5 and older, Linux before 2.6.36 IIRC, Windows 7 with default (buggy PoS msahci) driver partially, it swallows large trims etc.).

The only way to erase data on an SSD with 100% certainty is issueing a secure erase ATA command, this puts 21V on the substrate, emptying all flash cells at the same time. Needless to say this will delete all data, including partitioning and MBR, and shorten the longevity of the device by one cycle (usually out of 1500 to 3000 now for 25 nm MLC).

Using encryption on your wallet is pointless in this scenario unless no unencrypted version of it is ever written, including as part of swap or a hibernation file.

The bottom line is that if you are paranoid, don't use an SSD

No. Journal is the essential feature that makes the advantage of ext3/4 over ext2. If you disable that, the only remainig difference is details like maximum file size. You have a slow old file system then.

Because people ignore that TrueCrypt is no easier than any other encryption method. You can easily setup something, but it's not trivial to ensure that it is secure.

http://forum.bitcoin.org/index.php?topic=16246.0

It's the default of the file system creation tools. It not the default of any serious linux distro.

On todays drive dimensions that would make file system checks after violent system shutdowns take decades.

How can I verify if I'm using data=ordered or data=journal? This is my partition on archlinux:

/dev/sda4 home  ext4  defaults,noatime  0  2

@bcearl: I assume you don't use shred right? If so then how can you securely use GPG encryption? It sounds useless to me if I'm leaving traces behind in my disk whenever I decrypt to use my wallet.

Using journal=data really hurts performance. It's useful mostly for home users, who have low reliability. Most other file systems (NTFS, ReiserFS, XFS, etc.) don't even support data journaling.