xfs
[Top] [All Lists]

Re: XFS corruption on 3ware RAID6-volume

To: Erik Gulliksson <erik@xxxxxxxxxxxxxx>
Subject: Re: XFS corruption on 3ware RAID6-volume
From: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Date: Thu, 24 Feb 2011 06:01:42 -0500 (EST)
Cc: xfs@xxxxxxxxxxx
In-reply-to: <AANLkTi=ERpJLUUGWO_0xjecTPV3=w1GmXKBk0-uCch1L@xxxxxxxxxxxxxx>
References: <AANLkTinWByYooMnPL7BryPowDexBeiHJdh3aVh+fdm-a@xxxxxxxxxxxxxx> <20110223154651.54f0a8dc@xxxxxxxxxxxxxxxxxxxx> <AANLkTinsfwr5E7KkffwWOweWJLCmaLnLdtYA4g_m--b0@xxxxxxxxxxxxxx> <alpine.DEB.2.02.1102231022470.15181@xxxxxxxxxxxxxxxx> <AANLkTi=ERpJLUUGWO_0xjecTPV3=w1GmXKBk0-uCch1L@xxxxxxxxxxxxxx>
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)


On Thu, 24 Feb 2011, Erik Gulliksson wrote:

Hi again Justin,

This would seem to be the problem, you should go with Hiatchi next time.
You can use regular non-enterprise drives (Hiatchi) and they just work.
Seagate is a question
Samsung is a question
WD needs TLER.

This is valuable information, we might consider Hitatchi-disks next
time if we want to play cheap again.


As far as the problem at hand, I do not know of a good way to fix it unless
you had ls -lRi /raid_array output so you could map the inodes to their
original locations.  Sorry don't have a better answer..

No, I don't have full filename-inode mappings from before the
corruption. I guess such a list from the filesystem mounted with -o
"ro,norecovery" won't help here?

If the journal is corrupt, is there anyway to salvage only that part
so that the log replay will proceed further (ie "xfs_log_repair")? I'm
not nearly expert enough to parse the stacktrace triggered by mounting
the filesystem, but it seems some calls to xlog_recover_-functions are
involved, which make me think that the log is corrupt.

This is probably best answered by an XFS expert.

Could you also show tw_cli /c0 show diag ?

Justin.
<Prev in Thread] Current Thread [Next in Thread>