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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
