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)

Usage type presets

I tripped over something here: mkfs.ext4 -T huge /dev/device will actually create an ext2-like fs without a journal, because the huge type preset doesn't include has_journal and other modern options. I'm not sure how to fit that into the article as a warning, but suggesting people use -T just to select an inode ratio seems wrong. Dawidi (talk) 22:42, 29 April 2022 (UTC)

Did you actually check the filesystem features with dumpe2fs -h /dev/device after running mkfs.ext4? Since you're running mkfs.ext4, the features should include what is under the ext4 fs_type in /etc/mke2fs.conf. See also the -t option in the manual. — Lahwaacz (talk) 07:21, 30 April 2022 (UTC)

That's how I would have expected it to work, I'm not sure why it didn't; this is the first time I encountered that behaviour in several years, but I don't think I ever tried influencing the inode ratio before. According to mount messages no journal was created and it was treated as ext2. I tried dumpe2fs but aborted it after 15 minutes or so. Also curiously, that "wrong" mkfs run had spent over two hours (on this 8TB USB3 SMR disk) writing inode tables; a subsequent mkfs run with -t ext4 -i 65536 completed within seconds and produced a fs that properly mounts as a journaled ext4 without any mention of ext2. The manual also seems to imply that "using a name of the form ... mkfs.ext4" will only determine the default options if -t is not specified. This would mean that with the default /etc/mke2fs.conf, using any of the inode-ratio related -t options will always result in an ext2 fs, and this isn't a bug but intended behaviour. Dawidi (talk) 07:59, 30 April 2022 (UTC)

Well I just tried:

$ fallocate -l 1G test.img
$ mkfs.ext4 -T huge test.img
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 262144 4k blocks and 16384 inodes
Filesystem UUID: 92558d22-684f-45eb-937b-04b59c68c995
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

$ dumpe2fs -h test.img | grep features
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Journal features:         (none)

So there is a journal and the behaviour matches what the manual describes. Maybe you run mkfs.ext4 -t huge instead of mkfs.ext4 -T huge? That would explain the difference. — Lahwaacz (talk) 09:26, 30 April 2022 (UTC)

Oh my goodness, YES! Just confirmed from my bash_history I had actually used -t when I meant -T, somehow I glanced over how they are separate options. Sorry for that - you can remove this discussion when you're done with it, so it doesn't confuse more people. Dawidi (talk) 10:12, 30 April 2022 (UTC)