hi,
On Mon, Oct 15, 2001 at 04:22:37AM +0200, Nigel Kukard wrote:
> > and send the full xfs_repair output after this too.
>
> attatched, i used xfs_repair -nf /dev/hda3 on a readonly remount
This seems to confirm the root inode of this partition is indeed
corrupt - there is a directory entry to an inode which has been
marked as freed.
> if this is VERY VERY important let me know, i'll try sumone get it, i know it
> reports alot of problems so it might be hard for me to capture it. also taking
> into account the fs is mounted.
That's bad (that its mounted), since its also corrupted.
Before you mount these filesystems, if they're corrupted, you
_must_ first run xfs_repair (though you should also capture all
the console output when the corruption first occurs and send it
our way - we still haven't seen this). You also need a kernel
which isn't going to corrupt them again straight away.
So, what version of gcc was used to build this particular kernel?
If not kgcc, you should install that, change the top level kernel
Makefile to ensure kgcc is used (there is a big comment there), then
boot from your rescue disk (eg. the XFS 1.0.1 CD) and run xfs_repair
on the corrupt filesystems (saving the output somewhere).
Without knowing exactly which kernel versions and which compiler
was used to build the kernels which cause the initial corruption,
we aren't going to make much progress here.
On Sun, Oct 14, 2001 at 10:08:06PM -0500, Eric Sandeen wrote:
> Last time I saw this, it was on a >1TB filesystem, and the inode numbers
>From the xfs_db output it seems this is not the case:
xfs_db: xfs_db: magicnum = 0x58465342
blocksize = 4096
dblocks = 4849621
cheers.
--
Nathan
|