Talk:Ext4

Salt

Storing salt in the ext4 filesystem superblock for file-based encryption seem to be deprecated. I got this info from https://docs.kernel.org/filesystems/fscrypt.html#getting-the-per-filesystem-salt (ioctl FS_IOC_GET_ENCRYPTION_PWSALT). On last kernel I wasn't able to decrypt directory (no salt error) but on last LTS there is not problem. Someone with more knowledge should check it out

—This unsigned comment is by Ps756 (talk) 19:36, 12 April 2019‎. Please sign your posts with ~~~~!

FS_IOC_GET_ENCRYPTION_PWSALT still works, it's just "deprecated", so I'm not sure what exactly caused your problem. Some old kernels had a bug where they allowed you to use the encryption ioctls without actually enabling the encryption feature, so maybe that's it.

Anyway, since the e4crypt tool itself is also deprecated and no longer being updated (as it was really meant more as a demonstration, not as a proper user interface to filesystem encryption), I've updated the article to recommend using fscrypt instead. fscrypt stores its metadata in files, so it doesn't use the FS_IOC_GET_ENCRYPTION_PWSALT ioctl.

Synchronicity (talk) 06:26, 23 September 2019 (UTC)

crc32c_intel is obsolete

See upstream https://github.com/torvalds/linux/commit/55d1ecceb8d6a5c9ceff7c6528075bd0ce4e8366 and section 4.2.

The CPU specific crc32 modules were deprecated in favor of the generic implementation. It's crc32c now for both AMD and Intel CPUs. yvvki (talk) 05:22, 12 February 2025 (UTC)

Let's check linux-LTS has the ARCH_HAS_CRC32=y config before removing with next kernel. --Indigo (talk) 19:20, 12 February 2025 (UTC)

The problem comes when trying to add crc32_intel to the upcoming 6.14 kernel, which will warn Mkinitcpio generation that the module does not exist: ==> ERROR: module not found: 'crc32c_intel'.

Maybe add extra information for the upcoming and later kernel? yvvki (talk) 05:18, 13 February 2025 (UTC)

Good point with the warning, I think we should add a courtesy Template:Note to inform about that and simply remove the current crc32c_intel sentences. The suggestion to load the intel module manually should be legacy anyway.

Am I right that the warning means mkinitcpio exits with error, but the image should still mount the filesystem, since crc32c_generic or something else takes over? Assuming the user did not explicitly add crc32c_intel to the mkinitcpio modules array, would the error on image generation still appear? 6.14 is not in testing yet, which config did you use?

--Indigo (talk) 18:10, 13 February 2025 (UTC)

Indeed the image still being built, but I can't confirm if the hardware is still being utilized for accelerating checksum. I used the 6.14 RC and put the crc32 in the MODULES section. yvvki (talk) 04:10, 16 February 2025 (UTC)

Ok. I'm still on 6.13.2 and the following is output without any specific module config for crc32 (only autodetect):

$ lsmod |grep crc32

libcrc32c              12288  2 nf_conntrack,nf_tables
crc32c_generic         12288  0
crc32_pclmul           12288  0
crc32c_intel           12288  3

You should see more processes using libcrc32c, ideally it shows ext4 - that would be the equivalent hardware (SSE 4.2) support going forward. --Indigo (talk) 10:47, 16 February 2025 (UTC)