Re: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed

[Marcin Zajączkowski <mszpak@xxxxx>]

Barry Naujok wrote:
> > Subject: xfs_ncheck (actually xfs_db) eats a lot of memory 
> > and is killed
(...)
> > Recently I've got rescue CD with xfs_progs in version 2.8.11 
> > and tried 
> > to repair it. xfs_repair gave me about 150 files with names 
> > like inode 
> > numbers in /lost+found and 1500 "normal" named files in its 
> > subdirectory.
> > I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names 
> > corresponding with specified inode(s), but program had been runing 
> > several minutes, xfs_db had eaten all available memory 
> > (768MB) and was 
> > killed by system (whole system hung too). The second time I killed it 
> > (kill -15) when it ate whole available memory.
> > My file system has about 6GB and is filled with 95%.
>
> This is the second report of a smallish filesystem using all of the
> system's memory (the other being xfs_repair). Hopefully when I diagnose
> the problem with the previous report, I can fix the same issue with
> xfs_db and your filesystem.
>
> If it at all possible, can you xfs_copy the offending filesystem to a
> file and compress it and make it available to me to find/fix the
> problem.

Hmm, it won't be so easy. Compressed dump of a fielsystem before repair 
(I had to use dd, because xfsdump refused to cooperate) has 2,5GB.
Damaged files were (probably) only in one directory /usr/bin. Maybe I 
could reduce size of the image excluding few other directories (in xfsdump)?
Do you think that error would still occur?


> > Am I doing something wrong with xfs_db?
> > Is there any easier way to restore my files?
>
> Your files have been restored as much as possible. You'll have to work
> out what is in lost+found and move them back to their appropriate
> locations.

With files with "normal" names there is no problem. There are all from 
one directory (/usr/bin), but I'm unable (without xfs_ncheck) to map 
files with inode-like names with their normal names (150+ files). I 
tried with xfs_db and the way described in your FAQ, but I had some 
problems too.


> > Btw, xfs_check shows two lines:
> > link count mismatch for inode 1572882 (name ?), nlink 16, counted 15
> > link count mismatch for inode 2102297 (name ?), nlink 2, counted 3
> > Can it be reason for strange xfs_db behavior?
>
> No, this shouldn't be causing the xfs_db strange behaviour, but the
> nlink count mismatch is a problem with xfs_repair 2.8.11. Try and use
> xfs_repair 2.8.16 and later to fix this issue. Older versions before
> 2.8.11 will also fix the nlink issue.

I have some old system rescue CD with xfs_progs from line 2.7.x. Would 
it be ok?


Regards
Marcin