On 04/06/11 13:41, Dave Chinner wrote: >> Mar 30 14:04:44 dpmpool5 kernel: Please umount the filesystem, and >> rectify the problem(s) > > Did you do this? Not immediately, I wasn't the person immediately handling the issue. My colleague did unmount that filesystem and ran xfs_repair on it, and was successful in recovering most of the data. >> zerombr yes >> clearpart --all --initlabel >> part swap --size=1024 --asprimary >> part / --fstype ext3 --size=0 --grow --asprimary > > There your problem - hello random crap.... Oh crap. "--all" is all, indeed. Well, thanks for clarification, we were stupid after all :). > Given the nature of the problem, I have to assume you aren't using > FC zoning to prevent hosts from seeing disks that don't belong to > them? Nope, zoning unfortunately wasn't active. >> Would a "restore" of GPT partition table at the >> beginning of a disk from the copy at the end qualify as a possible >> candidate? > > No. The log messages have already told you what your next step is. I meant that as "a candidate for the thing to blame for corruption", not as a next step to undertake. Cheers, Jan
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
