| To: | Rui Gomes <rgomes@xxxxxx>, xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: xfs_repair segfault |
| From: | Carsten Aulbert <Carsten.Aulbert@xxxxxxxxxx> |
| Date: | Mon, 09 Mar 2015 16:55:00 +0100 |
| Cc: | Ãmar Hermannsson <omar@xxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <1145328183.409860.1425916240318.JavaMail.zimbra@xxxxxx> |
| Organization: | Max Planck Institute for Gravitational Physics - Albert Einstein Institute (AEI) |
| References: | <1145328183.409860.1425916240318.JavaMail.zimbra@xxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 |
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
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | xfs_repair segfault, Rui Gomes |
|---|---|
| Next by Date: | Re: xfs_repair segfault, Rui Gomes |
| Previous by Thread: | xfs_repair segfault, Rui Gomes |
| Next by Thread: | Re: xfs_repair segfault, Rui Gomes |
| Indexes: | [Date] [Thread] [Top] [All Lists] |