Bug 818078 - Ext3 Filesystem's journal got corrupted after power failure.
Summary: Ext3 Filesystem's journal got corrupted after power failure.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-02 07:33 UTC by Shubham Kumar Sharma
Modified: 2012-05-31 14:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-31 14:27:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Shubham Kumar Sharma 2012-05-02 07:33:39 UTC
Description of problem:
After Hard reboot of machine ext3 filesystem get corrupted and machine do not starts 

Version-Release number of selected component (if applicable):
RHEL 5.4

How reproducible:
Random. But there are many instances on web when this bug occurred. So, this seems to be a frequent problem.

Steps to Reproduce:
1.Run heavy data R/W
2. Shut down the machine by pulling the power cord
3.
  
Actual results:
File system should not get corrupted.

Expected results:
File system got corrupted.


Additional info:
Below is a snippet :
EXT3-fs error (device sda5): ext3_new_block: Allocating block in system zone - blocks from 6711321, length 1
Aborting journal on device sda5.
ext3_abort called.
EXT3-fs error (device sda5): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device sda5): ext3_free_blocks: Freeing blocks in system zones - Block = 6751321, count = 1
EXT3-fs error (device sda5) in ext3_free_blocks_sb: Journal has aborted

Comment 1 Shubham Kumar Sharma 2012-05-21 11:09:49 UTC
Anybody looking into this issue ?

Comment 2 Shubham Kumar Sharma 2012-05-21 11:10:20 UTC
Anybody looking into this issue ?

Comment 3 Ric Wheeler 2012-05-21 21:16:17 UTC
If you have a Red Hat support contract, you should talk to your support team to have them help review your configuration.

If you don't have a support contract, you should look at the upstream comments around how to configure "write barriers" (or just barriers some time) on storage. Barriers are not enabled by default in RHEL5 era kernels, you need to enable it. I would also suggest using a much more up to date kernel.

You also need to make sure that your storage is properly configured and that any LVM or device mapper under your file system supports barriers (some of this support was added only in RHEL6 era kernels which in general are much better for this kind of thing).

If all of this is way too confusing, you should simply disable the write cache on your storage device (hdparm can do that for a s-ata disk).

Good luck!

Comment 4 Shubham Kumar Sharma 2012-05-22 12:44:13 UTC
Just for my information.

Does patch for BZ#667673 also applicable for this issue ?
Also for all other ext3 issues, does ext4 patch will be applicable for ext3 as well ?

Comment 5 Ric Wheeler 2012-05-23 14:28:22 UTC
You should always try to use the most up to date kernels, but it is much more likely that your failure is simply do to not configuring the basics correctly.

Support would help you debug and analyse if you need more information.

thanks!

Comment 6 Shubham Kumar Sharma 2012-05-31 11:32:59 UTC
I want to know whether ext4 patch can work for ext3 system as well.
Please let me know about it.

Comment 7 Ric Wheeler 2012-05-31 14:27:22 UTC
Hi,

What you are describing is an incorrectly configured system in ext3. 

Fix the mount options and re-test please and re-open a bug through support if you still see an issue.

Best regards,

Ric


Note You need to log in before you can comment on or make changes to this bug.