Re: Speed and regression

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.