You should never use TRIM on encrypted drives.
With TRIM, your data is still encrypted, but you are revealing how much free space you have and where that free space (or inversely, data) is located. That's very normal and also the case when you use filesystem level encryption.
So there's nothing wrong with it, as long as you're aware what it does and doesn't do. Most encryption setups have glaring weak points elsewhere, no one will go and try to derive anything from raw data.
If you don't want free space revealed, you'll also have to initialize the drive with random data before you encrypt.
For most SSD it's also fine to use them like that, without TRIM. There's too much TRIM, with TRIM you can't recover deleted files, there's a danger of corrupting data (when trimming the wrong region, such bugs happen from time to time). SSDs have internal overprovisioning and wear leveling, if it's not enough you can just leave some unpartitioned (trimmed) space for additional overprovisioning, and leave the wear leveling entirely to the hardware. In that case, and with SSD prices dropping even further, you don't need a "flash-friendly" filesystem either. It's more important to use one that you trust, that won't lose your data, and you know how to recover when things go wrong. Well, you should have backups in any case, but...
]]>Low-level flash optimization such as wear-leveling are performed by the device controller so those are unaffected by the abstraction layer.
https://www.kernel.org/doc/html/latest/ … /f2fs.html
https://en.wikipedia.org/wiki/F2FS
LFS has two schemes for free space management: threaded log and copy-and-compac- tion. The copy-and-compaction scheme which is known as cleaning, is well-suited for devices showing very good sequential write performance, since free segments are served all the time for writing new data. However, it suffers from cleaning overhead under high utilization. Contrarily, the threaded log scheme suffers from random writes, but no cleaning process is needed. F2FS adopts a hybrid scheme where the copy-and-compaction scheme is adopted by default, but the policy is dynamically changed to the threaded log scheme according to the file system status.
I would expect any optimizations from sequential write speeds to be lost due to the abstraction layer. From what I've understood, F2FS also splits the disk into 6 sections and writes to them in parallel so that might suffer at times, but maybe the tests linked above prove otherwise. I didn't examine the details.
Related unanswered thread from 2018:
https://bbs.archlinux.org/viewtopic.php?id=242252
Using F2FS on LVM/LUKS is no worse or different than using it on a regular partition.
Like you said, if you want to use TRIM/discard with LUKS, you have to enable it, i.e. cryptsetup open --allow-discards. If you're using any initramfs/encrypt hook/pam stuff, it has to be done there. Or perhaps set it as --persistent with LUKS2, that might work too.
]]>