[Top] [All Lists]

Re: XFS corruption on 3ware RAID6-volume

To: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Subject: Re: XFS corruption on 3ware RAID6-volume
From: Erik Gulliksson <erik@xxxxxxxxxxxxxx>
Date: Thu, 24 Feb 2011 11:35:30 +0100
Cc: Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.02.1102231022470.15181@xxxxxxxxxxxxxxxx>
References: <AANLkTinWByYooMnPL7BryPowDexBeiHJdh3aVh+fdm-a@xxxxxxxxxxxxxx> <20110223154651.54f0a8dc@xxxxxxxxxxxxxxxxxxxx> <AANLkTinsfwr5E7KkffwWOweWJLCmaLnLdtYA4g_m--b0@xxxxxxxxxxxxxx> <alpine.DEB.2.02.1102231022470.15181@xxxxxxxxxxxxxxxx>
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.

Best regards
Erik Gulliksson

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