From nobody Sat Sep 03 03:17:26 2022 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MKKhz2djwz4c9QC for ; Sat, 3 Sep 2022 03:17:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MKKhy3J64z3VbH for ; Sat, 3 Sep 2022 03:17:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk1-f170.google.com with SMTP id j6so3101244qkl.10 for ; Fri, 02 Sep 2022 20:17:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=72ekmrUOYDEqpnLaOQQWVS80VBDs+LQZIj1aPj4QDsM=; b=srOI7/KYCHGBv/KEj3uJkeL51IW3+6+jWqaGrePQHCJr7Bu+/q8kl+zHGLAtrYzPxF fqsenyHxpzMpMHxX6zMzvdS6ZOErzoMnU+yyfPhji9NgD1Jiu9zLXA8ExSzrRrVj4FbZ biQB6UKPk0+NLCt9xDV0BraM/+Qy4jjPIZtW/VGNpM09+T6Pmy71L3CWwdDVoeQaEEIh BtWWKnbQCFL70vPGSwsJe7AfMAYnQ7hdHCnCl5+TgUnZxbnAZswBEUQkAF1DX9w7VNQU TfYo6GsVvA+/tBLo3NeV4G0jOoc/T7KV/YiQhr+6Kp1R+Ng3WE0rUWKXic4e1wcgMW/n 8Qbg== X-Gm-Message-State: ACgBeo3wOLDIhBL91+GhtX4q67ujP99Z+9Hsj+TxZTQ+TP+/Q/cNAYRH nROHrsXLQ1T1WyRhO16mK7/ACVjXyChdI0DW+80= X-Google-Smtp-Source: AA6agR7UG1Qaz06k/S9jLsMYFZGn6I58aZcJV79KET2kbgDok458fiQvVtDz3Gc39xvW7YGpcsUaA2lG8kXrIJiw6ME= X-Received: by 2002:a05:620a:1a81:b0:6c0:9f02:da81 with SMTP id bl1-20020a05620a1a8100b006c09f02da81mr6116588qkb.286.1662175057037; Fri, 02 Sep 2022 20:17:37 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 2 Sep 2022 21:17:26 -0600 Message-ID: Subject: Re: RFC: multiple concurrent I/O ops for copy_file_range(2) To: Rick Macklem Cc: FreeBSD Filesystems Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MKKhy3J64z3VbH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.170:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.170:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, Sep 2, 2022 at 9:11 PM Rick Macklem wrote: > > Hi, > > A recent discussion involving copy_file_range(2) performance > included a suggestion that, maybe, copying of subranges > should be done concurrently. > > Although I cannot be 100% sure, I think that this would > involve using multiple kernel threads (taskqueue or similar) > to issue I/O operations on the file system(s) for blocks > (of f_iosize maybe?) concurrently, to improve performance. > > Doing this in a system call is unusual, to say the least but, then, > copy_file_range(2) is an unusual system call to begin with. > > I have not attempted to code this up as of yet. > > So, what do others think of this idea? > > rick I'm skeptical. Is the intention to speed up copying on file systems that do or don't have an efficient VOP_COPY_FILE_RANGE implementation? For those that don't, I don't see any point in trying to beat the speed of the old cp(1). Apart from the problems that we've seen around hole size, does the copy_file-range-enabled cp match the older cp's performance?