oops, forgot to cc list.
-------- Original Message --------
On 2021/03/24 16:58, Eric Sandeen wrote:
This is a bug in root inode detection that Gao has fixed, and I really
need to merge.
In the short term, you might try an older xfsdump version, 3.1.6 or earlier.
---
In the short term -- I was dumping from a dumpdir
for a partition (just to make a copy of it on the new disk), but
there was no real requirement to do so, so I just dumped from
the "source" dir, which for whatever reason didn't have the problem.
My final try would have been to use rsync or such.
(Assuming you don't actually have a bind mount)
---
Not on that partition...
3.1.6? Hasn't 318 been out for quite a while?
I looked through my bins only have 312 and 314 (and 318)...
tried 314, but it started out with the same inode confusion -- didn't
wait until it started spitting out any other errors.
Sorry about that.
-Eric
---
No prob. Hey, one thing else you might wanna fix in
xfsdump/restore that was fixed in xfs_fsr, is to
put a posix_fadvise64(file->fd, offset, len, POSIX_FADV_DONTNEED)
before the read in xfsdump and on the write in xfs_restore.
That way they'll let go of memory and won't end up
with pegged memory through-out the 'copy' - unless it is already
there, and then I have some other problem :-( . But used all
8M of my swap (normally doesn't swap at all), shows a cpu
load of 3.4, and over 100% in wait-state.
Just a hopeful suggestion. I _think_ Dave put the
call in xfs_fsr (it would clear out memory everytime it ran, like
xfsdump/restore does now ;^)).
Thanks again for the possible cause...
