FAQ
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?idI4927

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.

Search Discussions

  • Gordon Messmer at Apr 14, 2009 at 6:11 pm

    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?idI4927
    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.
  • RedShift at Apr 14, 2009 at 8:20 pm

    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?idI4927
    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
  • Gordon Messmer at Apr 14, 2009 at 9:58 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedApr 13, '09 at 8:07p
activeApr 14, '09 at 9:58p
posts4
users2
websitecentos.org
irc#centos

2 users in discussion

Gordon Messmer: 3 posts RedShift: 1 post

People

Translate

site design / logo © 2022 Grokbase