On Thu, Dec 12, 2024 at 09:31:05PM +0300, Nikolai Zhubr wrote: > This is to report that after jumping from generic kernel 5.15.167 to > 5.15.170 I apparently observe ext4 damage. Hi Nick, In general this is not something that upstream kernel developers will pay a lot of attention to try to root cause. If you can come up with a reliable reproducer, not just a single one-off, it's much more likely that people will pay attention. If you can demonstrate that the reliable reproducer shows the issue on the latest development HEAD of the upstream kernel, they will definitely pay attention. People will also pay more attention if you give more detail in your message. Not just some vague "ext4 damage" (where 99% of time, these sorts of things happen due to hardware-induced corruption), but the exact message when mount failed. Also helpful when reporting ext4 issues, it's helpful to include information about the file system configuration using "dumpe2fs -h /dev/XXX". Extracting kernel log messages that include the string "EXT4-fs", via commands like "sudo dmesg | grep EXT4-fs", or "sudo journalctl | grep EXT4-fs", or "grep EXT4-fs /var/log/messages" are also helpful, as is getting a report from fsck via a command like "fsck.ext4 -fn /dev/XXX >& /tmp/fsck.out" That way they can take a quick look the information and do an initial triage over the most likely cause. > And because there are apparently 0 commits to ext4 in 5.15 since > 5.15.168 at the moment, I thought I'd report. Did you check for any changes to the md/dm code, or the block layer? Also, if you checked for I/O errors in the system logs, or run "smartctl" on the block devices, please say so. (And if there are indications of I/O errors or storage device issues, please do immediate backups and make plans to replace your hardware before you suffer more serious data loss.) Finally, if you want more support than what volunteers in the upstream linux kernel community can provide, this is what paid support from companies like SuSE, or Red Hat, can provide. Cheers, - Ted
