From owner-freebsd-current@freebsd.org Sat Jan 2 16:06:38 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 020884D4F4B for ; Sat, 2 Jan 2021 16:06:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7RbJ6vlzz4Z41; Sat, 2 Jan 2021 16:06:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f171.google.com with SMTP id s2so27127451oij.2; Sat, 02 Jan 2021 08:06:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Zf4MuNf2zgrISUPUo2noalj0Ny+1qvujTDMcAMqDUHU=; b=miUPsrwZoZ8c8m7Lh6SWlZXW2ONlCINsno0jdz1PQASqaDLnad15/EJo4spqeNRwSI ZMv+oQQ81B1BnXoKyzUrDv3PIOEjDgw/Ibaf+npsEUud8Sjdmh+pk2D1xOgQOm4Gi3Tv CoVNHZrCYNkzHLdFBqgYOUBYN8lvdqfFDJDRIXcg7bOtjgCHFw9Xecv+qDosvYNdrl4G G1VjfeuqqEvI9fB7+NNqAWk3kou42s4JwLyL9CEfTHyIIxopYRuGdInROY4WZWLyzK0Z pyTmB7sI8mbJTLN3JOBP6ponwKlmVGQ0TURk4f6XowV2UfTvSahPM14DTmTQLInh9fyo b9Eg== X-Gm-Message-State: AOAM532zgEoBXEwzrsr8ovcuOEjqaPQ0XC/SOb7utvU+0tASr+ysHBqR BuSNTAnv8N3wQdGcp6mc19miekGqlMk/qQT83Og= X-Google-Smtp-Source: ABdhPJwU4thJCMCc9SHOuvnFTGuacIIJrKe82H9moD0qF0+/LQ7BTBrHfqVrgCbhmDnhQdmMAflfaqckSwlwiAnQDoM= X-Received: by 2002:aca:af8f:: with SMTP id y137mr13730485oie.55.1609603595768; Sat, 02 Jan 2021 08:06:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 09:06:24 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Matthias Apitz , Alan Somers , FreeBSD CURRENT X-Rspamd-Queue-Id: 4D7RbJ6vlzz4Z41 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.26 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.171:from]; NEURAL_SPAM_SHORT(0.74)[0.745]; SPAMHAUS_ZRD(0.00)[209.85.167.171:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.171:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.171:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 16:06:38 -0000 On Sat, Jan 2, 2021 at 9:02 AM Matthias Apitz wrote: > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan S= omers > escribi=C3=B3: > > > > # dd if=3Dguru-20210102.tar.gz > of=3D/mnt/AcerC720/backups/guru-20210102.tar.gz > > > bs=3D8m > > > 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 caus= es > > > 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 =3D 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) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > > > > 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. > > > 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 > > > As I said, it can be reproduced using only the local file system. This > was setup recently on a SSD: > > # dmesg | grep ada0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number F995890846 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > ada0: Command Queueing enabled > ada0: 488386MB (1000215216 512 byte sectors) > > and by this procedure: > > # gpart create -s gpt ada0 > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > # newfs -U -t /dev/gpt/ssdrootfs > # newfs -U -t /dev/gpt/ssdvarfs > # newfs -U -t /dev/gpt/ssdusrfs > > # gpart show -l ada0 > =3D> 40 1000215136 ada0 GPT (477G) > 40 1024 1 ssdboot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 ssdrootfs (2.0G) > 4196352 4194304 3 ssdvarfs (2.0G) > 8390656 16777216 4 ssdswap (8.0G) > 25167872 975046656 5 ssdusrfs (465G) > 1000214528 648 - free - (324K) > > # mount -t ufs > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > When I run in the /usr fs the command > > # cp -p guru-20210102.tar.gz xxx > > it copies around 168M per minute. > > matthias > Is that copying from /usr to /usr, or from /usr to /var or /?