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?