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 theext4
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)
- 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
- 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 runmkfs.ext4 -t huge
instead ofmkfs.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)
- Well I just tried: