Re: xfsdump | xfsrestore resulting in files->orphanage

[L A Walsh <xfs@tlinx.org>]

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...