From: L A Walsh <xfs@tlinx.org>
To: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: xfsdump | xfsrestore resulting in files->orphanage
Date: Wed, 24 Mar 2021 17:43:39 -0700 [thread overview]
Message-ID: <605BDCBB.6070607@tlinx.org> (raw)
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...
next reply other threads:[~2021-03-25 0:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 0:43 L A Walsh [this message]
2021-03-25 1:16 ` xfsdump | xfsrestore resulting in files->orphanage Gao Xiang
-- strict thread matches above, loose matches on Subject: below --
2021-03-24 22:05 L A Walsh
2021-03-24 23:58 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=605BDCBB.6070607@tlinx.org \
--to=xfs@tlinx.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).