I'm wondering if this is a recoverable situation:
[root@ozu root]# xfs_repair /dev/hdb3
Phase 1 - find and verify superblock...
sb root inode value 18446744073709551615 inconsistent with calculated
resetting superblock root inode pointer to 18446744069414584448
sb realtime bitmap inode 18446744073709551615 inconsistent with
calculated value 13835051801809780865
resetting superblock realtime bitmap ino pointer to 18446744069414584449
sb realtime summary inode 18446744073709551615 inconsistent with
calculated value 13835051801809780866
resetting superblock realtime summary ino pointer to
Phase 2 - using internal log
- zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs
to be replayed. Mount the filesystem to replay the log, and unmount it
before re-running xfs_repair. If you are unable to mount the
filesystem, then use the -L option to destroy the log and attempt a
Note that destroying the log may cause corruption -- please attempt a
mount of the filesystem before doing this.
In the past, sometimes the entire contents of the disk end up in
lost+found after xfs_repair -L. I ran xfs_repair -n, and it seemed to
want to unlink quite a few inodes (thousands, including system files
that could not have possibly been in active use during operation). Yes,
the system crashed, I'm not absolutely positive I had write caching
turned off (I've been using hdparm -W 0) on this system.
It was running 2.4.18 with xfs 1.1, not the latest CVS stuff. Also, I
ran the checks on a system with xfsprogs-2.0.3-0.rpm installed.
Anybody can offer any hope, or do I mkfs now? If there's a recovery
from this, that would save me and my sysadmins countless hours of work
into the future, as we have perhaps 100 machines running xfs on linux.
christian rice director of technology
tippett studio 510.649.9711 l--xr-----