XFS: failed to read RT inodes

XFS: failed to read RT inodes

[Per Lundberg]

Hello,

After a hard drive failure (and no backup...) I am trying with all my
strength do recover the file systems... With no real success. I have
dumped over the two file systems in question to another, healthy disk
drive. After dumping back the data to a third hard disk, one of the
file system can be successfully mounted but with a huge number of
files in the lost+found directory (after recovery using xfs_repair).
Strange since the dump indicated only 11 bad sectors on that file
system.

However, the big (55 gig) file system cannot even be mounted and this
is troublesome since it contains the most valuable data. This is what
I get after doing xfs_repair on the volume:

Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes,
realtime, large block numbers, no debug enabled
Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem
Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10
Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes

The repair was done using Debian-compiled Linux kernel (2.6.17-2-k7)
using xfsprogs 2.8.11-1. Afterwards, I've upgraded the kernel to
2.6.22 and xfsprogs 2.9.4-2 but it doesn't really make much of a
difference.

I've tried to disable the realtime stuff afterwards, by mounting the
filesystem using rtdev=/dev/null but I only got the following message
out of that:

Jan 10 10:36:40 amos kernel: XFS: Invalid device [/dev/null], error=-15

*Any* ideas on how to proceed with this is greatly appreciated...
Thanks in advance.
-- 
Best regards,
Per Lundberg

Re: XFS: failed to read RT inodes

[Eric Sandeen]

Per Lundberg wrote:
> Hello,
> 
> After a hard drive failure (and no backup...) I am trying with all my
> strength do recover the file systems... With no real success. I have
> dumped over the two file systems in question to another, healthy disk
> drive. After dumping back the data to a third hard disk, one of the
> file system can be successfully mounted but with a huge number of
> files in the lost+found directory (after recovery using xfs_repair).
> Strange since the dump indicated only 11 bad sectors on that file
> system.
> 
> However, the big (55 gig) file system cannot even be mounted and this
> is troublesome since it contains the most valuable data. This is what
> I get after doing xfs_repair on the volume:
> 
> Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes,
> realtime, large block numbers, no debug enabled
> Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem
> Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10
> Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes

maybe try xfs_db on the device; "sb 0" and "p" commands to see what the
rt inodes are.

-Eric

Re: XFS: failed to read RT inodes

[Per Lundberg]

On Feb 2, 2008 4:53 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> > Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes,
> > realtime, large block numbers, no debug enabled
> > Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem
> > Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10
> > Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes
> maybe try xfs_db on the device; "sb 0" and "p" commands to see what the
> rt inodes are.

Thanks for the hint! However, what I did was do a full restore of the
volume again and then xfs_repair + xfs_repair -L. Now, I can mount it
- but *everything* (and I really mean literally everything) has been
put into lost+found. Slightly annoying to say the least, but still a
whole lot better than having lost it all.

I think it *could* be because of a bad imaging program (Image for
Windows). The first sector of the partition doesn't seem to come
through properly (after restore, it contains 512 0x00 bytes. Quite
wrong in other words, so that could be the reason for the breakage. I
guess I could put back the broken drive again and just "dd" over the
data to the working disk but when I tried to do that yesterday on
another partition, I got 500 or so bad sectors... compared to 11 with
Image for Windows. So either Image for Windows was lying to me or the
disk has been starting to fall apart even more. :-)
-- 
Best regards,
Per Lundberg