[SOLVED] F2FS and LUKS/LVM

cosmogroid · 2021-02-16 00:18:32

Is there any reason why the abstraction layer that results from using LUKS or LUKS+LWM would somehow prevent an F2FS filesystem from communicating with the SSD hardware in order to take advantage of the special optimizations that it includes? I really can't find much information on this other than LUKS being able to pass through TRIM commands.

Last edited by cosmogroid (2021-02-19 20:59:20)

frostschutz · 2021-02-16 00:51:13

F2FS is just another filesystem. It works on any block device. It doesn't depend on any specific type of hardware. There are no special optimizations achieved by communicating with the SSD hardware. It just does what it does and hopes for the best.

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.

Xyne · 2021-02-16 01:04:30

I don't know but I was curious about it so I started searching a bit. Here's one thread that claims that F2FS's optimizations yield benefits even on LUKS: https://superuser.com/questions/729551/ … filesystem

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

str0gg · 2021-02-16 08:23:33

You should never use TRIM on encrypted drives.

frostschutz · 2021-02-16 08:54:14

str0gg wrote:

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...

cosmogroid · 2021-02-19 20:59:02

Alright, I'm going to try F2FS with LVM on LUKS and see if I get any speed improvement over my current BTRFS on LUKS.

Arch Linux

#1 2021-02-16 00:18:32

[SOLVED] F2FS and LUKS/LVM

#2 2021-02-16 00:51:13

Re: [SOLVED] F2FS and LUKS/LVM

#3 2021-02-16 01:04:30

Re: [SOLVED] F2FS and LUKS/LVM

#4 2021-02-16 08:23:33

Re: [SOLVED] F2FS and LUKS/LVM

#5 2021-02-16 08:54:14

Re: [SOLVED] F2FS and LUKS/LVM

#6 2021-02-19 20:59:02

Re: [SOLVED] F2FS and LUKS/LVM

Board footer