On Thu, Mar 31, 2005 at 01:03:54AM +0200, Sven Gehr wrote:
> Am Mi 30.03.2005 23:49 schrieb Steve Lord <lord@xxxxxxx>:
>
> > >>Make sure you have the most recent xfsprogs package from oss.sgi.com
> > >>first though.
>
> > > I have installed xfsprogs. What can I do to correct the problem?
> > >
> >
> > It looks like you have a filesystem xfs_repair cannot cope with,
> > you need to have a dialog with someone who has time to dig into
> > the problem some more. XFS is not my day job anymore. That person
> > is probably Nathan Scott at SGI, who should be waking up and
> > starting to read email about now - he is in Australia.
>
> ok. Thank you very mutch for your help. Is Nathan Scott member in this
> list an read the mails?
Yes. :)
First, how large is this filesystem of yours? How much of that
space was used (if you remember)? Is it something you could make
an xfs_copy of, and put up somewhere for me to grab a local copy
of, to work on here?
Either way, we'll want to start by seeing if we can dump out that
inode thats confusing xfs_repair - inode number 134762498...
> > corrupt inode 134762498 (btree). Umount and run xfs_repair. fatal
> > error -- 990 - couldn' iget disconnected inode
(Ugh, we should figure out a way to get that silly message out of
the shared libxfs code).
You can dump the inode by pointing xfs_db at the device:
# xfs_db -r -c 'inode 134762498' -c 'print' /dev/mdXXX
If we can't get hold of the filesystem, and its not obvious whats
going wrong once we see the contents of the inode, we can still
start poking at the device with xfs_db and carefully remove the
references to that inode from XFS's ondisk structures to get to
the point that repair can finish its job (i.e., all is not lost).
cheers.
--
Nathan
|