Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

On Sat, Jan 2, 2021 at 7:59 AM Matthias Apitz <guru_at_unixarea.de> wrote:

>
> This is with:
>
> # uname -a
> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #23 r368166M: Thu
> Dec 17 13:12:37 CET 2020     guru_at_c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
> I copy often large backup files to an external USB disk and hit the
> following problem since updating to r368166:
>
> A transfer with dd(1) works fast and as expected (~70M / sec):
>
> # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz
> bs=8m
> 4601+1 records in
> 4601+1 records out
> 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec)
> # ls -lh guru-20210102.tar.gz
> -r--------  1 root  wheel    36G  2 ene.  12:19 guru-20210102.tar.gz
>
> When I use cp(1) what I normaly do the transfer is very poor and causes
> 100% CPU itilization:
>
> # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx
> ^C
>
> killed after 1 minute; transfered in 1 minute:
>
> # ls -lh /mnt/AcerC720/backups/xxx
> -r--------  1 root  wheel   168M  2 ene.  15:34 /mnt/AcerC720/backups/xxx
>
> 168*1024*1024/60 = 2936012 bytes/sec   ./. 76174956 bytes/sec
>
> Trussing the cp(1) process shows these sys calls:
>
> # truss -p 37655
> copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0)    = 2097152 (0x200000)
> copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0)    = 2097152 (0x200000)
> copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0)    = 2097152 (0x200000)
> copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0)    = 2097152 (0x200000)
> copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0)    = 2097152 (0x200000)
>
> The problem is unrelated to the external disk, also a copy
> in the local file system shows the same transfer speed of 168M per
> minute.
>
> Is this a known issue or a regressionc ?
>
> I see in the man page of copy_file_range(2) that this is new with
> FreeBSD 13...
>
>         matthias
>

Not an issue I've heard of before.  Could you please describe how your USB
and local disk are formatted?  Also, where is the source file stored?  It
could be that the source file's file system has a very slow implementation
of FIOSEEKDATA/FIOSEEKHOLE.
-Alan