Re: Speed and regression

[Robert Nichols]

On 9/28/24 19:56, Duffer wrote:
> On 2024-09-28 13:19, Robert Nichols via Any discussion of rdiff-backup wrote:
> > (Looks like I hit "Reply" instead of "Followup". Posting this to the list now.)
> >
> > On 9/27/24 17:00, Duffer wrote:
> > > It's been running 18 hours, so I hate to break it again but I really wish I 
> > > could figure out what it's doing. One of the backup directories (where I see 
> > > the tmp files) keeps growing and shrinking.
> >
> > If you find the PID of the rdiff-backup process ("pgrep -l rdiff-backup") you 
> > can run
> >    ls -l /proc/{PID}/fd
> > and see what files it is working on. You'll probably want to run that on the server. 
> > Something along the lines of "readlink /proc/{PID}/fd/9" will show just the 
> > appropriate link. For a locally run rdiff-backup, the FD is more likely 13. That link 
> > won't always be there.
> >
> > Here's a quickie I sometimes use:
> >
> >    N=50; while ((--N)); do readlink /proc/{PID}/fd/9 && break; sleep 0.2; done
> >
> > You can also use the "watch" for a continuous display of changes.
>
> Thank you! That was helpful. I've been using it to monitor and I can see 
> rdiff-backup going through various files. I'm still not sure what it's doing 
> but at least I can see that it's doing something. My guess is that it's going 
> to verify everything, which will take a long, long time.

When I see an rdiff-backup session taking a long time it's usually because it 
is saving compressed copies of a large number of deleted files. One example is 
a backup of a Fedora system which has might have had several kernel updates 
since the last backup. That means that several old kernels were deleted, and a 
large number of files in /usr/src/kernels etc. have to be saved in compressed 
form in the increments directory.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.