xfs_repair

xfs_repair

[Ashley Oviatt]

I am having the same problem as the person in this thread (Which problem 
is xfs_repair has been running for 16 hours on a 1 TB raid array):

http://www.linux.sgi.com/archives/xfs/2007-03/msg00061.html

It gave the same errors as this thread, saying that it could not use any 
of the super blocks it found. The last email in the thread says:

-----------------------------------------

xfs-repair did find candidate secondary superblocks - it discarded them
for some reason or another. If they were ok, all repair would have done
is copied them to block zero and then continued.

I'm suggesting that you manually do this step, and then see if repair
will run.

>/    Before wrapping this up, if you could just clarify a couple things.  If I/
>/    look at the bytes at the beginning of each physical part of the LVM's,/
>/    what am I looking for?  "XFSB"?/

yes.

>/    If I do find that byte string, why/
>/    couldn't xfs_repair find it when it did the scan and what do I do with it/
>/    if I do find one?/

As I said above, xfs-repair did find some, but rejected them for some
(unknown) reason. if you find one, copy it over block zero of the partition,
and see if repair will run. Like I said, though, you'll probably want to
back up th partition first, or at least run repair in no-modify mode.

--------------------------------------

The poster, Dave Chinner, says to manually copy the superblock to the 
right place, but not how to do it. I am familiar with dd, but would like 
to know the exact command or steps to take to replace the primary 
superblock manually with a secondary superblock.

I am using slackware linux 10 with an intel raid card.

Ashley


[[HTML alternate version deleted]]

xfs_repair

[Roman Hlynovskiy]

[-- Attachment #1.1: Type: text/plain, Size: 651 bytes --]

hello, after a server crush we are trying to get back access to data on
another server.

out setup is the following:
4 disks in md-array, lvm over it and xfs

xfs_check just stops with 'out of memory error'
xfs_repair after a long list of complains says:

corrupt dinode 2473604576, extent total = 1, nblocks = 0.  This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@oss.sgi.com.
cache_node_purge: refcount was 1, not zero (node=0xb43ab688)

fatal error -- 117 - couldn't iget disconnected inode

I captured this metadata file, but it's 2GB size.
is there a chance to fix the fs?

-- 
...WBR, Roman Hlynovskiy

[-- Attachment #1.2: Type: text/html, Size: 924 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_repair

[Eric Sandeen]

On 11/14/13, 11:51 AM, Roman Hlynovskiy wrote:
> hello, after a server crush we are trying to get back access to data on another server.
> 
> out setup is the following:
> 4 disks in md-array, lvm over it and xfs
> 
> xfs_check just stops with 'out of memory error'

xfs_check is deprecated & doesn't scale; don't bother.
Use xfs_repair -n if you want a readonly check.

> xfs_repair after a long list of complains says:
> 
> corrupt dinode 2473604576, extent total = 1, nblocks = 0.  This is a bug.
> Please capture the filesystem metadata with xfs_metadump and
> report it to xfs@oss.sgi.com <mailto:xfs@oss.sgi.com>.
> cache_node_purge: refcount was 1, not zero (node=0xb43ab688)
> 
> fatal error -- 117 - couldn't iget disconnected inode

Are you using latest xfsprogs?

> I captured this metadata file, but it's 2GB size.
> is there a chance to fix the fs?

how big is it if you compress it?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs