https://bugzilla.kernel.org/show_bug.cgi?id=217769 --- Comment #4 from Mariusz Gronczewski (xani666@xxxxxxxxx) --- > It's essentially an unexpected/inconsistent in-memory state, as opposed to an > on-disk structure that was found to be corrupt. Shouldn't that also set filesystem as "dirty" ? The problem is that this *basically* makes system unbootable without intervention; OS thinks it is clean so it doesn't run xfs_repair, then driver crashes without marking it unclean, reboot and process repeats. The crash also blows every mounted XFS system which means even if log partition doesn't have that problem none of logs will persist. I had to reformat /var/log in ext4 to even gather them on my laptop > I presume that it boots ok now post-repair? Yes > Do you know if this was the root or /boot filesystem or something else? It's > still a mystery about how filesystems get into this state; we should never > have a clean filesystem that requires no log recovery, but with unlinked > inodes ... recovery is supposed to clear that. It was root in both cases, we keep /boot on ext4 So far (well, we got few hundred more machines to upgrade) I've only seen that on old ones, might be some bug that was fixed but left the mark on filesystem ? > It may have persisted on this filesystem for a very long time and it's just > recent code changes that have started tripping over it, but I've always had a > hunch that /boot seems to show the problem more often. That would track, I only saw that on old machines (I think they were formatted around 4.9 kernel release, some even earlier). I just had another case on machine but this time reading certain files triggered it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
