[Top] [All Lists]

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

To: "'Marcin Zajączkowski'" <mszpak@xxxxx>, <linux-xfs@xxxxxxxxxxx>
Subject: RE: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed
From: "Barry Naujok" <bnaujok@xxxxxxxxxxxxxxxxx>
Date: Mon, 18 Dec 2006 12:24:21 +1100
In-reply-to: <em1c1v$ig8$1@xxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
Thread-index: AcchO+Hkj6O0EbHPTqSusDHkZwevMgBBXi3g

> -----Original Message-----
> From: xfs-bounce@xxxxxxxxxxx [mailto:xfs-bounce@xxxxxxxxxxx] 
> On Behalf Of Marcin Zajaczkowski
> Sent: Sunday, 17 December 2006 4:58 AM
> To: linux-xfs@xxxxxxxxxxx
> Subject: xfs_ncheck (actually xfs_db) eats a lot of memory 
> and is killed
> Hi,
> A few weeks ago I described problem with my file system 
> (caused by a bug 
> in kernel 2.6.17) - 
> http://oss.sgi.com/archives/xfs/2006-11/msg00271.html
> 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
> 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

> 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.

<Prev in Thread] Current Thread [Next in Thread>