xfs
[Top] [All Lists]

Re: xfs_repair problem

To: "Armando Navarro" <qoajnv@xxxxxx>
Subject: Re: xfs_repair problem
From: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 17 Oct 2000 09:57:43 -0400
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: "Armando Navarro" <qoajnv@usc.es> "xfs_repair problem" (Oct 16, 12:50pm)
References: <000901c0375e$da674b70$eb4a90c1@qogolem.usc.es>
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi Armando,

On Oct 16, 12:50pm, Armando Navarro wrote:
> Subject: xfs_repair problem
> 
> Dear Sir:
> I have installed the beta release of xfs for linux as a
> patch on 2.4.0-test5 kernel. I have compiled succesfully
> the kernel and the xfs tools.  I tried to read an old IRIX
> xfs disk. The problem is that by a mistake the disk 
> was signed by NT, so the first sector is corrupted.

Unfortunately thats probably the worst possible place to
overwrite on an XFS filesystem.  xfs_repair can usually
recover it though, provided you have enough good secondary
superblocks (sounds like you don't though)...

> I tried to use the xfs_repair utility.  A bad magic number
> in first superblock is found, so the program tried to find
> a secondary superblock. xfs_repair says that a candidate
> secondary superblock was found but it could not verify it.
> 

Can you send the actual xfs_repair output?  It will help
with understanding exactly where repair is giving up.
I'm guessing its around line 741 of repair/sb.c - but
would want to know for sure.

> Is there any possibility to repair the disk with xfs_repair?
> 

_if_ the only thing that has been overwritten is the
primary superblock (first 512 bytes), _and_ we have
at least one other good secondary superblock, it should
be possible to recover.  If we cannot get xfs_repair to do
the recovery, but we know we have one good secondary SB,
then there is always xfs_db in expert mode... (i.e. "if
at first you don't succeed - use a bigger hammer"),
and then repair later once we've written as much of the
primary SB back as we can... this would be a non-trivial,
error-prone exercise though, so I wouldn't recommend it.

It would involve using gdb to break into repair to dump
the contents of the secondary SB when it finds one, then
using the xfs_db write command (expert mode) to reset each
field in the first superblock, and afterward running repair
again to see if it can stitch together the rest of the SB.

Its something you'd want to practice on an empty spare disk
first though, but in theory it should be possible -
# mkfs.xfs /dev/scratch
# dd if=/dev/zero of=/dev/scratch count=1 bs=512
# gdb xfs_repair
...break in "verify_sb"; run /dev/scratch; print sb
# xfs_db -x /dev/scratch
...sb 0, help write, write, write, write...
# xfs_repair /dev/scratch

... and if that works, and you really only overwrote the
first 512 bytes on your real filesystem, then xfs_repair
might be able to recover the rest on your real filesystem
too.

I'd consider that approach an absolute last resort though.

hope this helps.

-- 
Nathan

<Prev in Thread] Current Thread [Next in Thread>
  • xfs_repair problem, Armando Navarro
    • Message not available
      • Re: xfs_repair problem, Nathan Scott <=