I think that behind your description, there is a misconception. The unencrypted data is not stored on the disk at any point. When you write to a file in the encfs filesystem, the write instruction goes to the encfs process; the encfs process encrypts the data (in memory) and writes the ciphertext to a file. The file names, as well as the file contents, are encrypted. Reading a file undergoes the opposite process: encfs reads the encrypted data from the disk file, decrypts it in memory and passes the plaintext to the requesting application.
When you run the encfs command, it does not decrypt any data. It only uses the password that you supply to unlock the filesystem's secret key. (This is actually a decryption operation, cryptographically speaking, but a different type from what happens with the file data. I will not go into more details here.)
1) Encfs is not exactly “moving blocks around”; it is decoding blocks when it reads them. Encfs is a filesystem because it behaves like one: you can store files on it, when it's mounted.
2) Encfs is not a “true” filesystem because it doesn't work independently. Encfs only provides an encryption layer; it uses an underlying filesystem to actually store data and metadata (metadata is auxiliary information about files such as permissions and modification times).
3) Virtual filesystem is another way to say that encfs itself doesn't store any data, it needs an underlying filesystem (see (2) above) for that. Encrypted means just that: encfs stores the data that you put in it in an encrypted form, which cannot be decrypted without the key. Another program could read the data stored by encfs if and only if that other program had access to the key (which requires the password that the key is protected with).
4) The fusermount command sets up a FUSE mount point. You would not normally call it directly, because a FUSE filesystem is implemented by a user-mode process which you have to start anyway, and that process (e.g. encfs) will take care of setting up the mount point. Unmounting a FUSE filesystem, on the other hand, is a generic operation, you can always do it by calling fusermount -u.
Don't get misled by the fact that only writeback mentions internal filesystem integrity.
With ext3, whether you use journal, ordered or writeback, file system metadata is always journalled and that means internal file system integrity.
The data modes offer a way of control over how ordinary data is written to the file system.
In writeback mode, metadata changes are first recorded in the journal and a commit block is written. After the journal has been updated, metadata and data write-outs may proceed. data=writeback can be a severe security risk: if the system crashes while appending to a file, after the metadata has been committed (and additional data blocks allocated), but before the data has been written (data blocks overwritten with new data), then after journal recovery that file may contain blocks filled with data from previously deleted files – from any user1.
So, if data integrity is your main concern and speed is not important, data=journal is the way to go.
Best Answer
I would say no.
1: The swap space does not use the same concept of free space as filesystem
2: what matter is that you always keep at least 25% free space on your SSD (this value was given to me by Sandisk representative on the phone), to allow proper work of wear levelling.
=> as long as the disk has spare clusters to work with, and to perform WL, it does not really matter if 5% of your disk is never trimmed, or continusouly re-written: even when YOU rewrite the same logical or physical sectors, WL will use different clusters anyway, when you write large enough blocks.
The question remains unanswered if you are using a whole disk for swapping. A whole disk used for swap may suffer premature aging, if never trimmed.
The other question is: does the swap driver support discard ? ext3/ext4 do.
Maybe, if your swap occupies a significant % of the disk, if you can, you could discard/trim the swap space during shutdown: if you can, after killing all services, do swapoff, and find a way to discard the swapspace (since I am not an expert, and to not leave the question unanswered, I would propose to mkfs.ext3, fstrim, mkswap again - there are probably other better solutions. Check if shutdown is due to UPS. ).