Linux 6.10 Improves Performance For Opening Unencrypted Files

[phoronix]

Phoronix: Linux 6.10 Improves Performance For Opening Unencrypted Files

FSCRYPT is the file-system encryption framework within the Linux kernel for supporting optional encryption on file-systems like EXT4, F2FS, Btrfs, and others. With Linux 6.10 an optimization is coming for enhancing the performance of opening files on file-systems supporting FSCRYPT-based encryption but when the files are unencrypted...

https://www.phoronix.com/news/Linux-6.10-FSCRYPT

[xAlt7x]

Phoronix: Linux 6.10 Improves Performance For Opening Unencrypted Files

FSCRYPT is the file-system encryption framework within the Linux kernel for supporting optional encryption on file-systems like EXT4, F2FS, Btrfs, and others.

According to the readme at the official fscrypt github repo, it supports only EXT4, F2FS. UBIFS and CephFS.
Unfortunately, support for Btrfs has not yet been mainlined.

[User42]

I was about to say, how did I miss that... But it's noce it's being merged.

[mb_q]

I actually hope Btrfs will not get merged; fscrypt is a very dirty hack formed by the limitations of EXT. What people wanted is an ability to have encrypted partitions that somewhat occupy the same pool of space, not to encrypt per-directory, this is madness. But Btrfs literally has partitions over the same data storage layer, subvolumes, so it would be better off just offering encrypted subvolumes.

[ahrs]

I actually hope Btrfs will not get merged; fscrypt is a very dirty hack formed by the limitations of EXT. What people wanted is an ability to have encrypted partitions that somewhat occupy the same pool of space, not to encrypt per-directory, this is madness. But Btrfs literally has partitions over the same data storage layer, subvolumes, so it would be better off just offering encrypted subvolumes.

I still don't understand why we want this "per-subvolume" or "per-folder" encryption in the first place. If I want to encrypt something I'm going to encrypt the whole thing and that can happen at a layer below the filesystem with LUKS / cryptsetup.

If for some reason there's still a use-case for this then you can use a loopback device, or something FUSE based.

At the same time I see no reason not to add it though (unless complexity is an issue?). ZFS got encrypted datasets recently.

[mb_q]

I still don't understand why we want this "per-subvolume" or "per-folder" encryption in the first place. If I want to encrypt something I'm going to encrypt the whole thing and that can happen at a layer below the filesystem with LUKS / cryptsetup.

If for some reason there's still a use-case for this then you can use a loopback device, or something FUSE based.

At the same time I see no reason not to add it though (unless complexity is an issue?). ZFS got encrypted datasets recently.

The main use is to have each home directory encrypted with its user password. Even for one user, you might want to have the machine to be able to reboot and perform some functions not needing home to be mounted, but still keep user data encrypted when the user is not logged in. This is how most modern smartphones work, and how "immutable" distros want to work (together with dm-verity & friends).

FUSE is slow & may leak meta-data like file size or number, loopbacks require size allocated up-front & are also slow, especially if underlying FS is COW. ZFS is actually brain-dead simple compared to Btrfs and has more devel freedom due to its independent status.