unsatisfied with the ext3 and jfs filesystems I decided to switch to xfs. I am
running Debian Sid with kernel 2.4.20, so I applied the xfs-patch deb-package
for this kernel, which seems to be a snapshot from 2002-12-29. All went fine
and finally all harddisks and partitions with exception of /boot had been
formatted with xfs.
Unfortunately I applied the patch after configuring the kernel via 'make-kpkg
-added-patches xfs', which seems to cause no problems with the system or xfs
at all, but makes it impossible to compile other modules for this kernel
later. So I had to patch a clean kernel-source before configuring and
compiling the kernel again, now with new nvidia modules. There were no
changes with kernel version or configuring.
After rebooting the new kernel I ran into a severe problem with one
xfs-formatted partition (/dev/hdh2). When the new kernel booted it couldn't
mount /dev/hdh2 and showed these errors:
XFS: bad magic number
XFS: SB validate failed
'xfs_check /dev/hdh2' shows:
xfs_check: unexpected XFS SB magic number 0x00000000
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
xfs_check: cannot read root inode (22)
xfs_check: cannot read realtime bitmap inode (22)
bad superblock magic number 0, giving up
'xfs_repair -n /dev/hdh2' of xfsprogs 2.4.4-1 does shows:
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
found candidate secondary superblock...
unable to verify superblock, continuing...
and so on...
until it has finished its task:
.......Sorry, could not find valid secondary superblock
This happens after a clean shutdown and reboot without any crashes. All other
xfs-partitions mount fine and show no errors, even the third (/dev/hda3) at
hdh (the first is swap). This harddisk is connected together with three other
disks to a Promise onboard raid controller (PDC20276), but all work as normal
ide-drives. I am sure that this is an xfs filesystem at /dev/hdh2 and I could
read and write to its files without problems before recompiling and rebooting
the new kernel. Lilo stays in the MBR of the first HD (hda), so it can't not
be responsible for the destruction of the XFS superblock.
Changing back to the old kernel/modules didn't help, neither booting with
other linux distributions (Knoppix 3.2, Mandrake 8.2). There are always the
same error messages.
I did a backup of the partition with dd (77.??? records in and out) and tried
xfs_repair with log flushing and without -n, but with the same result.
Now I have an untouched xfs-partition with a corrupted superblock and a backup
image, perhaps both with all stored data, but no way to access it. Is there
anybody here who can help me or give me some advices what to do next. Perhaps
there is a possibility to restore the 77 GB of files and directories.
Thanks in advance