Bug 10899 - xfs on raid5 hang and serious disk corruption
Summary: xfs on raid5 hang and serious disk corruption
Status: RESOLVED DOCUMENTED
Alias: None
Product: File System
Classification: Unclassified
Component: XFS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Christoph Hellwig
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-12 08:19 UTC by dev
Modified: 2010-02-10 10:32 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.25
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Crash log and following boot (98.38 KB, text/plain)
2008-06-12 08:28 UTC, dev
Details

Description dev 2008-06-12 08:19:37 UTC
Latest working kernel version: 2.6.24
Hardware Environment: x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD 
Software Environment: Gentoo GNU/Linux

Problem Description: Sudden system hang (hard lock, magic sysreq not working), after reboot out of sync raid5, after resync xfs_check failed because of corrupt superblock, xfs_repair restored superblock with secondary copy, but detected open transfer in metalog, suggested mount failed because of missing root node. repair succeeded with xfs_repair -L
End of day: Nothing left on disk ca. 360Gb out of 600Gb in lost+found most of it usable. System log before hang and initial boot afterwards attached. If anyone needs more information, feel free to ask( sry faq is down at the moment)

Steps to reproduce: Thanks, do not even want to try!
Comment 1 dev 2008-06-12 08:28:08 UTC
Created attachment 16462 [details]
Crash log and following boot
Comment 2 Christoph Hellwig 2010-02-09 22:26:35 UTC
This was with disk write caches enabled, and raid code that didn't support barriers.  I suspect you simply lost the content of all disk write caches.
Comment 3 dev 2010-02-10 10:32:04 UTC
As never happened again since, I'll just leave it closed but i still think that it is kind of funny for it to loose content that had not been touched for month.

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