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