Am Do 31.03.2005 01:55 schrieb Nathan Scott <nathans@xxxxxxx>:
> 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>:
> 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).
In first time after the crash the sort of the RAID devices was false. I
was operate from a rescue-system but the rescu-system was resync the
RAID. After this I change the order of the SCSI devices manuell. After
this the rescue-system rebuild the RAID too.
Destroy the rebuild with wrong device-order the data?
with best regards