Bug 692748 - Hard shutdowning of a machine with fs operations on sata caused fs corruption
Summary: Hard shutdowning of a machine with fs operations on sata caused fs corruption
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: Unspecified
OS: Linux
high
high
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: 2011-04-01 02:51 UTC by Igor Zhang
Modified: 2011-04-07 01:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-07 01:45:40 UTC
Target Upstream Version:


Attachments (Terms of Use)
When fs corruptions were found for the first time, its dmesg. (43.19 KB, application/octet-stream)
2011-04-01 02:52 UTC, Igor Zhang
no flags Details
When fs corruptions were found for the first time, its test log. (21.47 KB, application/octet-stream)
2011-04-01 02:53 UTC, Igor Zhang
no flags Details
When fs corruptions were found for the second time, its dmesg. (41.63 KB, application/octet-stream)
2011-04-01 02:53 UTC, Igor Zhang
no flags Details
When fs corruptions were found for the second time, its test log. (3.68 KB, application/octet-stream)
2011-04-01 02:54 UTC, Igor Zhang
no flags Details
When fs corruptions were found for the third time, its dmesg. (41.64 KB, application/octet-stream)
2011-04-01 02:54 UTC, Igor Zhang
no flags Details
When fs corruptions were found for the third time, its test log. (3.69 KB, application/octet-stream)
2011-04-01 02:55 UTC, Igor Zhang
no flags Details

Description Igor Zhang 2011-04-01 02:51:19 UTC
Description of problem:
Hard shutdowning of a machine with fs operations on sata caused fs corruption
when I did power failure testing for
rhel6.1(https://tcms.engineering.redhat.com/run/18635/?from_plan=1232), I
found:
For the test scenario "nobarriers enabled and local write cache on" with workload "fs_mark -d /media/sdb/dir -s 51200 -n 4096 -L 10 -r 8 -D 128" (without the option -S 0), I have tested this for three times and they all failed.
Seems RHEL6.1 Ext4 is risky in this scenario. Logs are attached.

Version-Release number of selected component (if applicable):
RHEL6.1-20110323.1
Kernel 2.6.32-125.el6.x86_64

How reproducible:
At times

Steps to Reproduce:
1.Please view https://tcms.engineering.redhat.com/run/18635/?from_plan=1232 and
the case "power testing: on SATA disk".

  
Actual results:
Filesystems corruptions found.


Expected results:
Filesystems are sane.


Additional info:

Comment 1 Igor Zhang 2011-04-01 02:52:23 UTC
Created attachment 489289 [details]
When fs corruptions were found for the first time, its dmesg.

Comment 2 Igor Zhang 2011-04-01 02:53:00 UTC
Created attachment 489290 [details]
When fs corruptions were found for the first time, its test log.

Comment 3 Igor Zhang 2011-04-01 02:53:41 UTC
Created attachment 489291 [details]
When fs corruptions were found for the second time, its dmesg.

Comment 4 Igor Zhang 2011-04-01 02:54:11 UTC
Created attachment 489292 [details]
When fs corruptions were found for the second time, its test log.

Comment 5 Igor Zhang 2011-04-01 02:54:38 UTC
Created attachment 489293 [details]
When fs corruptions were found for the third time, its dmesg.

Comment 6 Igor Zhang 2011-04-01 02:55:05 UTC
Created attachment 489294 [details]
When fs corruptions were found for the third time, its test log.

Comment 8 Ric Wheeler 2011-04-01 12:39:29 UTC
Hi Igor,

With nobarriers and write cache enabled, this is expected behavior.

Unless I misunderstand the setup, this should be closed as NOTABUG.

Thanks!

Comment 9 RHEL Program Management 2011-04-04 02:42:25 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.


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