On Thu, May 09, 2013 at 05:11:13PM +0200, Filippo Stenico wrote:
> On Thu, May 9, 2013 at 1:39 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > On Wed, May 08, 2013 at 07:30:05PM +0200, Filippo Stenico wrote:
> > > Hello,
> > > -m option seems not to handle the excessive memory consumption I ran
> > into.
> > > I actually ran xfs_repair -vv -m1750 and looking into kern.log it seems
> > > that xfs_repair invoked oom killer, but was killed itself ( !! )
> > That's exactly what the oom killer is supposed to do.
> > Yeah, some sacrifice needed.
> > > This is last try to reproduce segfault:
> > > xfs_repair -vv -P -m1750
> > I know your filesystem is around 7TB in size, but how much RAM do
> > you have? It's not unusual for xfs_repair to require many GB of
> > memory to run succesfully on filesystems of this size...
> > it is around 11 TB, 7.2 used.
> I have 4 G ram, but xfs_repair -vv -m1 says I need 1558
> root@ws1000:~# xfs_repair -vv -P -m 1 /dev/mapper/vg0-lv0
> Phase 1 - find and verify superblock...
> - max_mem = 1024, icount = 29711040, imem = 116058, dblock =
> 2927886336, dmem = 1429632
> Required memory for repair is greater that the maximum specified
> with the -m option. Please increase it to at least 1558.
That's the minimum it requires to run in prefetch mode, not the
maximum it will use.
4GB RAM on a badly corrupted 7TB filesystem is almost certainly not
enough memory to track all the broken bits that need tracking. Add
20-30GB of swap space and see how it goes...