[Top] [All Lists]

Re: xfsdump -- not enough memory to dump attributes? w/>20G free -- how

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: xfsdump -- not enough memory to dump attributes? w/>20G free -- how much does it need?
From: "Linda A. Walsh" <xfs@xxxxxxxxx>
Date: Wed, 26 May 2010 00:34:55 -0700
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20100525164244.GB18666@xxxxxxxxxxxxx>
References: <4BF7D787.4020903@xxxxxxxxx> <20100525164244.GB18666@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

Christoph Hellwig wrote:
The error comes directly from the libhandle listing routine, which
is a straight forward wrapper around the kernel syscall in current

What xfsprogs version are you using?  I noticed your xfsdump is
rather old, so making sure you have recent XFS userspace and
possibly also the kernel would help debugging this.

Also can you check using strace if the ENOMEM comes directly from
the attr_list_by_handle ioctl?
xfsprogs/xfsdump both at 3.0.1-2.1 from suse11.2 which would likely be 3.0.1 with some patchlevel from suse.
kernel is 2.6.34 (vanilla).

strace would be pretty difficult considering how far it is into a dump
before it is triggered.

Maybe I should try getting updated tools and see
if it "goes away"...

looks like I need to build xfsprogs before xfsdump?

looks like best way to pull current ver is from .git.

will try rebuilding and see if I have any luck...

BTW -- how do you tell the version of the xfs progs from the individual progs -- I'm going from the installed rpm
name, but if I build from the git, that won't be helpful.
I don't see a VERSION command in xfsdump/restore?

Is there one with any of the xfs tools?

<Prev in Thread] Current Thread [Next in Thread>