xfs_repair can indeed take a lot of memory, although I don't have a good
rule of thumb for how much it might take for a given filesystem. 3G
does seem excessive, but you have 200G of "very small files" so there
may be a lot of data to work with.
It's possible that there are memory leaks in repair that cause it to use
more than necessary; I suppose it's also possible that the filesystem is
corrupt in such a way that repair is getting confused and going off "in
the weeds" allocating memory in a broken loop or something, hard to say
without a debugger.
I fixed a few memory leaks in 2.6.4, and you're using 2.6.5, so at least
you have those. for now, I'd suggest creating a whole lot of swap and
give it another go; it would be nice to be able to watch xfs_repair work
on this filesystem to see what it's doing. You might also get the very
latest xfsprogs (2.6.10 I think).
just to get an idea of what your filesystem looks like, could you
unmount it and run this command to print out some of the superblock
xfs_db -r -c "sb 0" -c "p" /dev/<device>
On Tue, 2004-04-27 at 09:45, Torsten Wolf wrote:
> On Di, 27 Apr 2004, Christian Guggenberger wrote:
> >On Tue, 2004-04-27 at 11:35, Torsten Wolf wrote:
> >> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> >several people experienced this, as seen on lkml. (not only with xfs)
> >Could you go for a try with 2.4.26 ? (try with the oom killer first,
> >then, if it still not works, without the oom killer enabled)
> With oom killer enabled, I get
> Apr 27 16:36:31 sycorax kernel: Out of Memory: Killed process 1281
> while without oom killer the kernel message is the same as above. And
> yes, both runs again on the flaky machine as there is no box around I
> could update to 2.4.26.
> But let me ask a more fundamental question: Is this the normal behaviour
> of xfs_repair to allocate such an amount of memory? Is there a way to
> estimate how much memory is needed to recover a damaged filesystem?
Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc. 651-683-3102