Red Hat Bugzilla – Bug 167710
EXT3 filesystem on RAID1 partition is remounted read-only and corrupted
Last modified: 2015-01-04 17:21:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
The system has problem with root (/) filesystem on RAID1 (mirror) partition.
After about one week uptime I found that the filesystem was remounted read-only and fsck showed lots of errors.
This is quite strange, that it happened only to root filesystem, but not to /var and /home (which are on separate partitions on the same disks).
The problem happened twice in two weeks, for the first time fsck -f /dev/md0 corrected the filesystem, the second time whole filesystem went to lost+found.
The disks are ok (checked with smartctl and badblocks non-destructive r-w).
In /var/log/messages I found:
kernel: EXT3-fs error (device md0): ext3_new_inode: reserved inode or inode > inodes count - block_group = 0, inode=1
kernel: Aborting journal on device md0
kernel: EXT3-fs error (device md0) in ext3_new_inode: IO failure
kernel: EXT3-fs error (device md0) in ext3_create: IO failure
kernel: ext3_abort called
kernel: EXT3-fs error (device md0): ext3_journal_start_sb: Detected aborted journal
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install fresh FC4 on RAID1 partition (created during installation).
/dev/md0 - /
/dev/md1 - swap
/dev/md2 - /var
/dev/md3 - /home
2. Let the system work for a week (mailserver with antivirus, web server). Not too busy.
Actual Results: Found the system half-working - some tasks were unable to complete becouse of read-only /tmp
The filesystem was corrupted.
Expected Results: The system shoud work without corrupting filesystem.
The system is 1xPIII 1.4 GHz, 3 x 36GB SCSI disks, Intel SDS2 motherboard
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (18.104.22.168). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
Seems like a bug was addressed in kernel 2.6.12-1.1447_FC4.
The system works 17 days without a crash, whereas with the previous kernel it
would crash within a week.