xfsdump | xfsrestore resulting in files->orphanage

xfsdump | xfsrestore resulting in files->orphanage

[L A Walsh]

copying a disk to a replacing disk I am using
xfsdump on the fromdir and xfsrestore on the todir.

I finish another disk a short while ago with no probs, but this
disk starts out with a weird message from xfsdump:


xfsdump: NOTE: root ino 192 differs from mount dir ino 256, bind mount?

Then later, when it starts restoring files on the target,
all the files end up in the orphanage:

xfsrestore: 9278 directories and 99376 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: NOTE: ino 709 salvaging file, placing in 
orphanage/256.0/Library/Music/ Maria/Cover-Inside.jpg
xfsrestore: NOTE: ino 710 salvaging file, placing in 
orphanage/256.0/Library/Music/ Maria/Cover-Outside.jpg

The files look "fine" on the source
Never had a simply "copy" go so wrong...

What might be causing this?

Thanks!
-l

Re: xfsdump | xfsrestore resulting in files->orphanage

[Eric Sandeen]

On 3/24/21 5:05 PM, L A Walsh wrote:
> copying a disk to a replacing disk I am using
> xfsdump on the fromdir and xfsrestore on the todir.
> 
> I finish another disk a short while ago with no probs, but this
> disk starts out with a weird message from xfsdump:
> 
> 
> xfsdump: NOTE: root ino 192 differs from mount dir ino 256, bind mount?
> 
> Then later, when it starts restoring files on the target,
> all the files end up in the orphanage:
> 
> xfsrestore: 9278 directories and 99376 entries processed
> xfsrestore: directory post-processing
> xfsrestore: restoring non-directory files
> xfsrestore: NOTE: ino 709 salvaging file, placing in orphanage/256.0/Library/Music/ Maria/Cover-Inside.jpg
> xfsrestore: NOTE: ino 710 salvaging file, placing in orphanage/256.0/Library/Music/ Maria/Cover-Outside.jpg
> 
> The files look "fine" on the source
> Never had a simply "copy" go so wrong...
> 
> What might be causing this?

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.

(Assuming you don't actually have a bind mount)

Sorry about that.

-Eric

Re: xfsdump | xfsrestore resulting in files->orphanage

[Gao Xiang]

Hi,

On Wed, Mar 24, 2021 at 05:43:39PM -0700, L A Walsh wrote:
> 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.

Not sure get all your point.

That is because commit ("xfsdump: handle bind mount targets") was included in
3.1.7. So it would be better to confirm if 3.1.6 works as expected.

In principle, 3.1.6 should work if applying to non-bindmount root dir. (I mean
if no new non-identify potential issue here)

Thanks,
Gao Xiang

Re: xfsdump | xfsrestore resulting in files->orphanage

[L A Walsh]

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