Bug 216317
Summary: | "ext4: lblock 0 mapped to illegal pblock" after upgrading to 5.19.0 | ||
---|---|---|---|
Product: | File System | Reporter: | David Korth (gerbilsoft) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | RESOLVED CODE_FIX | ||
Severity: | high | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.19.0 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
David Korth
2022-08-02 05:49:49 UTC
Distribution is Gentoo Linux amd64, 17.1 hardened profile. After doing some searching, it looks like this commit may fix the issue: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=f50f5a5eac8092fb9b3365ca4b1d7407cdab8427 ext4: fix reading leftover inlined symlinks Since commit 6493792d3299 ("ext4: convert symlink external data block mapping to bdev"), create new symlink with inline_data is not supported, but it missing to handle the leftover inlined symlinks, which could cause below error message and fail to read symlink. ls: cannot read symbolic link 'foo': Structure needs cleaning EXT4-fs error (device sda): ext4_map_blocks:605: inode #12: block 2021161080: comm ls: lblock 0 mapped to illegal pblock 2021161080 (length 1) Fix this regression by adding ext4_read_inline_link(), which read the inline data directly and convert it through a kmalloced buffer. Reading the various commits, it seems that ext4's inline_data option previously supported inlining symlinks, but as of v5.19.0, that's no longer supported. The patch restores read-only compatibility, but new symlinks will not be inlined. Is there any particular reason why symlink inlining was removed, and/or does the new method work better than inlining? This must be fixed in just released 5.19.2. |