I opened bug 494927 with Red Hat after seeing this kernel error on two different hosts, just a few days after updating or installing CentOS 5.3: https://bugzilla.redhat.com/show_bug.cgi?id=494927
Has anyone else seen this yet? The patch that RH included in kernel-2.6.9-78.0.17.EL.src.rpm to fix the problem appears to have been in their 2.6.18 rpm since revision 15, so something else is apparently causing the same problem.
I'm running bonnie++ in a loop on a VM running the affected kernel hoping to duplicate the problem.
Gordon Messmer wrote:
I opened bug 494927 with Red Hat after seeing this kernel error on two different hosts, just a few days after updating or installing CentOS 5.3: https://bugzilla.redhat.com/show_bug.cgi?id=494927
In an attempt to confirm this bug, I set up a system under KVM and started three loops to generate filesystem activity. I ran bonnie++ as two different users in separate directories under /var/tmp, and an additional loop copying /usr to a directory under /var/tmp and then removing it. The /var filesystem became corrupt relatively quickly.
I'm now nearly certain that there is a severe filesystem corruption bug in 2.6.18-128.1.6.el5. Please, if you are running this kernel, reboot your systems into single user mode and check your filesystems with "fsck -f". Your filesystems may appear clean despite corruption. My test system exhibited this behavior. Even though the corruption should have been obvious (files could not be deleted), the FS was marked clean.
Gordon Messmer wrote:
Gordon Messmer wrote:
I opened bug 494927 with Red Hat after seeing this kernel error on two different hosts, just a few days after updating or installing CentOS 5.3: https://bugzilla.redhat.com/show_bug.cgi?id=494927
In an attempt to confirm this bug, I set up a system under KVM and started three loops to generate filesystem activity. I ran bonnie++ as two different users in separate directories under /var/tmp, and an additional loop copying /usr to a directory under /var/tmp and then removing it. The /var filesystem became corrupt relatively quickly.
I'm now nearly certain that there is a severe filesystem corruption bug in 2.6.18-128.1.6.el5. Please, if you are running this kernel, reboot your systems into single user mode and check your filesystems with "fsck -f". Your filesystems may appear clean despite corruption. My test system exhibited this behavior. Even though the corruption should have
Just to be clear, this corruption appears on the HOST, not inside the KVM virtual machine?
Glenn
RedShift wrote:
Gordon Messmer wrote:
In an attempt to confirm this bug, I set up a system under KVM and started three loops to generate filesystem activity. I ran bonnie++ as two different users in separate directories under /var/tmp, and an additional loop copying /usr to a directory under /var/tmp and then removing it. The /var filesystem became corrupt relatively quickly.
Just to be clear, this corruption appears on the HOST, not inside the KVM virtual machine?
No, the host is Fedora 10. The KVM guest is CentOS 5.3 running kernel 2.6.18-128.1.6.el5. The filesystem activity caused corruption on the filesystem being stressed (barely).
I've also seen corruption on a CentOS 5.3 install running on a physical machine.
One of my friends is now attempting to reproduce the corruption on Red Hat's release of the same package, and I'm trying to reproduce the corruption on 2.6.18-128. I suggest that anyone using that kernel check their filesystems and report any corruption that they find.
-
Gordon Messmer -
RedShift