On Sun, Apr 20, 2008 at 12:38 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> James Klaas wrote:
> > I've been struggling to recover/repair an XFS partition that is on a
> > Linux software raid. This is on Ubuntu Feisty (7.04) with xfsprogs
> > v2.8.18.
> >
> > When I try to mount the system, it attempts a recovery:
> >
> > [127094.470809] Filesystem "md0": Disabling barriers, not supported by
> > the underlying device
> > [127094.471954] XFS mounting filesystem md0
> > [127094.613551] Starting XFS recovery on filesystem: md0 (logdev: internal)
> > [127094.858897] Filesystem "md0": XFS internal error
> > xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller
> > 0xf8eda9fb
>
> The simplest approach, though perhaps not the least prone to data loss,
> is to run xfs_repair with the -L option to zero out the log before
> proceeding.
>
> You could also mount -o ro,norecovery first to back up as much critical
> data as possible, beforehand.
>
> -Eric
>
Thank you, that actually worked this time for me. I was probably not
doing it right before.
Now, I have a copy from when I "mount -o ro,norecovery" the partition
and after I ran "xfs_repair -L" on the partition.
I got a lot of lost+found entries which I went through and decided to
mostly throw away (not important files). Most showed up on the copy
of the norecovery mounted filesystem anyway.
One puzzling thing though. Many files have different md5sums on the
copied filesystem versus the repaired filesystem. I've gone through a
few of them, but I've been unable to determine a real difference. Do
you have any advice as to which files to trust more? I'm inclined to
trust the files on the repaired filesystem.
James
|