Description of problem: We have installed several hosts on F10 and F8 . At the moment every 1-2 days, one of our F10-Hosts are running to a filesystem crash. The F8 hosts are running fine with the same hardware components... All F10-release-kernels... How reproducible: Steps to Reproduce: 1. Run F10 without reboot 3-4 weeks
Thanks for report. Filesystem is just a system package with basic directory layout. Filesystems generally (and ext3 belongs to them) are on kernel. Therefore reassigning. Anyway - more informations about the system hardware will be required to address the issue properly.
A little bit of detail on your actual errors would be extremely helpful. If you have a "filesystem crash" I presume you have some errors in dmesg? Perhaps some e2fsck output? Thanks, -Eric
Ok, here some more details from the last filesystem crash... ============================================================ /var/log/messages : Oct 4 04:25:31 storageXXX kernel: imklog 3.22.1, log source = /proc/kmsg started. Oct 4 04:25:31 storageXXX rsyslogd: [origin software="rsyslogd" swVersion="3.22.1" x-pid="2099" x-info="http://www.rsyslog.com"] (re)start Oct 5 02:50:29 storageXXX kernel: EXT3-fs error (device md3): ext3_dx_find_entry: bad entry in directory #50118689: rec_len % 4 != 0 - offset=905216, inode=1818326113, rec_len=26725, name_len=45 Oct 5 02:50:29 storageXXX kernel: EXT3-fs error (device md3): ext3_dx_find_entry: bad entry in directory #50118689: rec_len % 4 != 0 - offset=905216, inode=1818326113, rec_len=26725, name_len=45 Oct 5 02:50:29 storageXXX kernel: EXT3-fs error (device md3): ext3_add_entry: bad entry in directory #50118689: rec_len % 4 != 0 - offset=0, inode=1818326113, rec_len=26725, name_len=45 Oct 5 09:24:06 storageXXX kernel: EXT3-fs error (device md3): ext3_add_entry: bad entry in directory #50118664: rec_len % 4 != 0 - offset=0, inode=993473850, rec_len=14963, name_len=57 Oct 5 09:25:11 storageXXX kernel: EXT3-fs error (device md3): ext3_add_entry: bad entry in directory #50118664: rec_len % 4 != 0 - offset=0, inode=993473850, rec_len=14963, name_len=57 Oct 5 10:53:46 storageXXX kernel: EXT3-fs error (device md3): ext3_add_entry: bad entry in directory #50118664: rec_len % 4 != 0 - offset=0, inode=993473850, rec_len=14963, name_len=57 ============================================================ Kernel: <= 2.6.27.29-170.2.78.fc10.x86_64 > 2.6.27.29-170.2.78.fc10.x86_64 not tested ============================================================ Last Filesystemcrash (md3): 2009-09-12 2009-08-20 2009-07-13 ============================================================ fsck.ext3 output (only last lines): Inode 50380440 ref count is 2, should be 1. Fix? yes Unattached inode 50380480 Connect to /lost+found? yes Inode 50380480 ref count is 2, should be 1. Fix? yes Unattached inode 50382120 Connect to /lost+found? yes Inode 50382120 ref count is 2, should be 1. Fix? yes Unattached inode 50382582 Connect to /lost+found? yes Inode 50382582 ref count is 2, should be 1. Fix? yes Pass 5: Checking group summary information /dev/md3: ***** FILE SYSTEM WAS MODIFIED ***** /dev/md3: 4418916/61054976 files (6.7% non-contiguous), 206019596/244189984 blocks ============================================================ Fedora8 and Fedora9 Server are working fine. Filesystem on Backport F10 Kernel to F8 are stable, only F10-System has this kind of problems. F11 and F12 not testet yet
Directory corruption sounds a lot like drive write caches being lost after a power loss, without barrier support from the filesystem. Did the system lose power? If you're on md, unfortunately barriers aren't passed through properly for most raid configurations (how is md3 set up?) You could also try disabling write cache on the drives in the raid with hdparm and see if the situation goes away. -Eric
Can the reporter answer the questions in comment #4? thanks, -Eric
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days