xfs_repair segfault

Rui Gomes rgomes at rvx.is
Mon Mar 9 11:11:58 CDT 2015


Hello Carsten,

Thank you for the quick reply, we tried many different combinations, without the -m flag the result is the same.
New gdb dump in the attachment replacing the -m with -v

Regards 

------------------------------- 
Rui Gomes 
CTO 


RVX - Reykjavik Visual Effects 
Seljavegur 2, 
101 Reykjavik 
Iceland 


Tel: + 354 527 3330 
Mob: + 354 663 3360

----- Original Message -----
From: "Carsten Aulbert" <Carsten.Aulbert at aei.mpg.de>
To: "Rui Gomes" <rgomes at rvx.is>, "xfs" <xfs at oss.sgi.com>
Cc: "omar" <omar at rvx.is>
Sent: Monday, 9 March, 2015 15:55:00
Subject: xfs_repair segfault

Hi Rui

On 03/09/2015 04:50 PM, Rui Gomes wrote:
> Full output and GDB Backtrace in the attachment, do you guys have any
> advice how can we get xfs_repair to do a clean run?
> 

At the very least (though I'm not sure if that will already fix it) I
think you need to change the -m flag:


/usr/sbin/xfs_repair -n -P -m 500000000000000 /dev/sdb1

according to man page:

 -m maxmem
              Specifies the approximate maximum amount of memory, in
megabytes, to use for xfs_repair.  xfs_repair has its own internal block
cache  which  will  scale
              out up to the lesser of the process's virtual address
limit or about 75% of the system's physical RAM.  This option overrides
these limits.

              NOTE: These memory limits are only approximate and may use
more than the specified limit.

and I doubt your machine has that much memory, possibly just drop it for
now.

Cheers

Carsten
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdb2.txt
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20150309/eb6c7fb7/attachment.txt>


More information about the xfs mailing list