On Mon, 2023-10-30 at 22:35 +1100, fedora(a)eyal.emu.id.au wrote:
On 30/10/2023 21.40, Patrick O'Callaghan wrote:
> On Mon, 2023-10-30 at 18:22 +1100, fedora(a)eyal.emu.id.au wrote:
> > Should I blame rsync (or the way I use it)?
> >
> > Next, I will do a plain 'cp -a' between the original source (sdh
> > on
> > /sata) and target(md127 on /data1) to see how it goes.
>
> If you say how you use it, someone might be able to answer that.
> Give
> the exact command line with all options (e.g. if you have strict
> change
> detection you might be checksumming every file on the source before
> deciding to copy it).
First, I already did this test and it still chokes after a few GB.
The problem is still there
and it is not only an rsync problem. But why does rsync use 100% CPU?
I thought that I gave the command but I did not initially, yet when I
show the output of 'ps' it says:
sudo rsync -aHSK --stats --progress --checksum-choice=none --
no-compress -W /sata/backups/tapes /data1/no-backup/old-backups/
so there it is.
Nothing obvious at first glance. The '-W' option should mean that rsync
is simply copying files without it's usual delta detection, which could
have been the culprit.
poc