Red Hat Bugzilla – Bug 215522
xfs_reapir gets killed by OOM on FC6 recovery CD
Last modified: 2013-07-02 22:30:57 EDT
Description of problem: xfs_repair recovery program for XFS from xfsprogs
package gets killed by OOM-killer on FC6 recovery CD.
Version-Release number of selected component (if applicable):
Name : xfsprogs
Arch : i386
Size : 2.9 M
Repo : installed
Summary: Utilities for managing the XFS filesystem.
How reproducible: Always
Steps to Reproduce:
1. Boot from FC6 recovery CD
2. type `xfs_repair /dev/xfs_partition
3. watch top on the other console how xfs_repair eats memory and finally
"... was killed by OOM"
program does not finish it s work, gets killed by kernel because it eats all
application should work as expected -- go through all blocks and inodes to
was able to recover with old version (about 2 years old) of xfs_repair
how big, and how populated (inode count) is the filesystem you are repairing?
it was a / directory on my working machine -- 15GB total, 8GB used. Naturally
there are lots of small files in / but that's should handled.
If you look at the 'top' output on the other console while xfs_repair is working
-- it grows in size every second and it takes all available memory in less than
a minute. So, I pretty sure its bug and not a feature.
PS: sorry, cannot look at the inode count right now, / is mounted.
df -i will give you inode counts...
But, this doesn't sound like a particularly large filesystem, just wanted to
check. I'll ping the sgi repair maintainer & see if they have any idea. How
much memory was in your machine? I wonder if swap is enabled in FC6 rescue mode...
> df -i
oops, did know that.
So for the record:
Filesystem Inodes IUsed IFree IUse% Mounted on
1867776 288312 1579464 16% /
I dunno if swap is enabled by default, even I it will be, I guess it won't help
much if you need to repair any FS of a descent size (with the current FC6 repair CD)
Thanks for the reply,
PS: mem size is 768MB
Konstantin, thanks. Let me ping the sgi guys on this one...
PS: I did some experiments with xfs_repair last night, running `xfs_reapir
/dev/fedora3/storage' (small xfs partition, about 10GB) resulted in kernel OOPS
See attached photo.
Created attachment 141821 [details]
photo of kernel OOPS
well, that's not really an oops, it's detected a soft lockup. And although it
is the xfs_repair process, I can't imagine what it would be doing to cause
Most recent xfs_repair should be much better for both memory consumption and
speed. There's not a lot we can do to fix the FC6 recovery CD, as it's spun and
If you still have xfs_repair OOM problems with more recent xfsprogs (or more
recent recovery CDs), please file another bug...
F8test now has the most recent xfsprogs, and F7 should get it in a bit (it's in