xfs
[Top] [All Lists]

corrupt xfs filesystem -- xfs_repair dumps core

To: linux-xfs@xxxxxxxxxxx
Subject: corrupt xfs filesystem -- xfs_repair dumps core
From: Willi Langenberger <wlang@xxxxxxxxxxxxx>
Date: Tue, 23 Apr 2002 18:35:46 +0200
Reply-to: Willi.Langenberger@xxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi!

We have the following problem with a fileserver in one of our
departments.

Distribution: RedHat-7.1

Kernel:
  # cat /proc/version
  Linux version 2.4.3-SGI_XFS_1.0.1 (root@xxxxxxxxxxxxxxxxxxxxxxxxxxx) \
  (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) \
  #1 Mon Jul 9 14:27:56 CDT 2001

Now upgraded to:
  # cat /proc/version 
  Linux version 2.4.9-31SGI_XFS_1.1 (root@permit) \
  (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) \
  #1 Wed Apr 17 12:21:35 CDT 2002

BTW, the xfs filesystem lives on /dev/sdb (an unpartitioned scsi
disk -- i didn't know that this is possible, but my colleage said,
that it has worked until now).

The problems began with disappearing directories. We tried a
xfs_repair (1.2.8), but without luck. Unfortunatly, my colleague
hasn't saved the output from that run.

Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump:

  # /sbin/xfs_repair /dev/sdb
  Phase 1 - find and verify superblock...
  Phase 2 - using internal log
          - zero log...
  xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion 
`start_blk != 0 || *last_blk != start_blk' failed.
  Aborted (core dumped)

Should this happen? The Kernel Upgrade from 2.4.3-SGI_XFS_1.0.1 to
2.4.9-31SGI_XFS_1.1 made no difference.

When we try the -n flag to xfs_repair, we get a more promising output:

  # /sbin/xfs_repair -n /dev/sdb
  Phase 1 - find and verify superblock...
  Phase 2 - using internal log
          - scan filesystem freespace and inode maps...
          - found root inode chunk
  Phase 3 - for each AG...
          - scan (but don't clear) agi unlinked lists...
          - process known inodes and perform inode discovery...
          - agno = 0
          - agno = 1
          - agno = 2
        [...agno 3-1998...]
          - agno = 1999
          - process newly discovered inodes...
  Phase 4 - check for duplicate blocks...
          - setting up duplicate extent list...
          - check for inodes claiming duplicate blocks...
          - agno = 0
  inode block 8 multiply claimed, state was 4
  inode block 9 multiply claimed, state was 4
  inode block 10 multiply claimed, state was 4
  inode block 11 multiply claimed, state was 4
          - agno = 1
          - agno = 2
        [...agno 3-1998...]
          - agno = 1999
  No modify flag set, skipping phase 5
  Phase 6 - check inode connectivity...
          - traversing filesystem starting at / ... 
          - traversal finished ... 
          - traversing all unattached subtrees ... 
          - traversals finished ... 
          - moving disconnected inodes to lost+found ... 
  Phase 7 - verify link counts...
  No modify flag set, skipping filesystem flush and exiting.


Needless to say, that there very important data on the filesystem, and
that we have no backup! Is there any chance, to get the data back?
Anybody out there, who can help?

Any hints are highly appreciated!

(and please let me know, if i should provide other information)


Thank You,


\wlang{}

-- 
Willi.Langenberger@xxxxxxxxxxxxx                 Fax: +43/1/31336/702
Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria


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