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 Version: 2.8.11 Release: 3.fc6 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" Actual results: program does not finish it s work, gets killed by kernel because it eats all available memory Expected results: application should work as expected -- go through all blocks and inodes to repair filesystem. Additional info: 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... Thanks, -Eric
> df -i oops, did know that. So for the record: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/fedora3-system 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, Konstantin
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 this... strange.
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 done. 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 updates-testing now). Thanks, -Eric