Am Do 31.03.2005 01:55 schrieb Nathan Scott <nathans@xxxxxxx>:
Hallo Nathan,
> > > 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)?
The Partion is 135,6GB. ~20-30GB in use.
> 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?
I think it is to big to transver?
> 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
ok, i have do that. Look in the attachment.
> I 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).
ok, I hope the best.
sven
output.txt
Description: Text document
|