[Top] [All Lists]

Re: how cant I rebuild the superblock

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: how cant I rebuild the superblock
From: Sven Gehr <sven@xxxxxxxxxxxxx>
Date: Thu, 31 Mar 2005 09:35:29 +0200 (CEST)
Cc: Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20050330235545.GD867@frodo>
Organization: dreampixel
References: <20050330185324.GA12530@xxxxxxxxxxxxxxxxxxxxx> <22377952.1112209168690.OPEN-XCHANGE.WebMail.wwwrun@postgirl> <20050330190118.GA12758@xxxxxxxxxxxxxxxxxxxxx> <12241337.1112210187657.OPEN-XCHANGE.WebMail.wwwrun@postgirl> <20050330192000.GA13002@xxxxxxxxxxxxxxxxxxxxx> <120224.1112215280479.OPEN-XCHANGE.WebMail.wwwrun@postgirl> <424B124B.3070706@xxxxxxx> <20000831.1112216715240.OPEN-XCHANGE.WebMail.wwwrun@postgirl> <424B1EDF.6060508@xxxxxxx> <19480755.1112223834401.OPEN-XCHANGE.WebMail.wwwrun@postgirl> <20050330235545.GD867@frodo>
Reply-to: sven@xxxxxxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
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.


Attachment: output.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>