From owner-svn-src-all@freebsd.org Sun Sep 20 02:27:22 2020 Return-Path: Delivered-To: svn-src-all@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 658E83F745D; Sun, 20 Sep 2020 02:27:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (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 4BvBL129jyz3bJY; Sun, 20 Sep 2020 02:27:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f52.google.com with SMTP id 95so1912782ota.13; Sat, 19 Sep 2020 19:27:20 -0700 (PDT) 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:cc; bh=Envy6Z/q0Srmbm4/nCERcMjCqtYMRLusfSsfF05bIFA=; b=qJ3Yiqc5j9WMYtIoXdLvYQM8v64FQfgety7CblDBuKWUc1lUKXq9nJiVZ93EjUvFB1 88rIVNkeCcF4U3GWw0LKpNCtaCRAckBx7YwZ2p5yz2aYKZOiAZU+q1tEC+zkINHLfn9/ C9G8LxYsiZhYHe179bYEoXzYe3YgBbNzNELzZGTZrhgWBhJh8yM9T8c4vQm7eAOannj/ ZTi2am1bHsCescnmt4MpIYfOfQ74qBiiVFYx8nYO6U9Dlt6WN1LgZFa+Phrvb60ogCiY 35UTu+EpG9CoQgNfCb0aHp8Lb5EZmKCyU+TxMOCIYAD8n+zmAXXYVCjozbwiZpf4P8Ss db3w== X-Gm-Message-State: AOAM533Ddm5kRxD2RvWvFx2pbStvwKPw+NkcyiLh+9OqBCYPL7U9rDbJ oiP2/0U8dD+BdDXrs9UXPC3mv5FC1uSQf5d6jYI= X-Google-Smtp-Source: ABdhPJyeFld5p+XpymY8PwYEl8vwjGWtJVbJseHJe+DWh01/Yn9ig/YddseZmBxQefmhQYqz+3qPuUHbjCWGZ5jOhmo= X-Received: by 2002:a05:6830:1e30:: with SMTP id t16mr28311799otr.18.1600568839777; Sat, 19 Sep 2020 19:27:19 -0700 (PDT) MIME-Version: 1.0 References: <202009112049.08BKnavL032212@repo.freebsd.org> <20200911214327.GY94807@kib.kiev.ua> <20200919233232.GC94807@kib.kiev.ua> In-Reply-To: <20200919233232.GC94807@kib.kiev.ua> From: Alan Somers Date: Sat, 19 Sep 2020 20:27:08 -0600 Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: Konstantin Belousov Cc: Rick Macklem , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" X-Rspamd-Queue-Id: 4BvBL129jyz3bJY 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.210.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.19 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.52:from]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.94)[-0.943]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.39)[-0.390]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.52:from]; NEURAL_HAM_MEDIUM(-0.86)[-0.856]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 02:27:22 -0000 On Sat, Sep 19, 2020 at 5:32 PM Konstantin Belousov wrote: > On Sat, Sep 19, 2020 at 11:18:56PM +0000, Rick Macklem wrote: > > Alan Somers wrote: > > >On Fri, Sep 11, 2020 at 3:52 PM Rick Macklem > wrote: > > >Konstantin Belousov wrote: > > >>On Fri, Sep 11, 2020 at 08:49:36PM +0000, Alan Somers wrote: > > >>> Author: asomers > > >>> Date: Fri Sep 11 20:49:36 2020 > > >>> New Revision: 365643 > > >>> URL: https://svnweb.freebsd.org/changeset/base/365643 > > >>> > > >>> Log: > > >>> cp: fall back to read/write if copy_file_range fails > > >>> > > >>> Even though copy_file_range has a file-system agnostic version, it > still > > >>> fails on devfs (perhaps because the file descriptor is > non-seekable?) In > > >>> that case, fallback to old-fashioned read/write. Fixes > > >>> "cp /dev/null /tmp/null" > > >> > > >>Devices are seekable. > > >> > > >>The reason for EINVAL is that vn_copy_file_range() checks that both in > and out > > >>vnodes are VREG. For devfs, they are VCHR. > > > > > >I coded the syscall to the Linux man page, which states that EINVAL is > returned > > >if either fd does not refer to a regular file. > > >Having said that, I do not recall testing the VCHR case under Linux. > (ie. It might > > >actually work and the man page turns out to be incorrect?) > > > > > >I will test this case under Linux when I get home next week, rick > > I'll admit I haven't tested this in Linux to see if they do return > EINVAL. > > > > >Since there's no standard, I think it's fine for us to support devfs if > possible. > > 1 - I think this is a good question for a mailing list like > freebsd-current@. > > 2 - I see Linux as the de-facto standard these days and consider POSIX no > > longer relevant, but that's just mho. > > 3 - For NFSv4.2, the Copy operation will fail for non-regular files, so > if you > > do this, you will need to handle the fall-back to using the > generic code. > > (Should be doable, but you need to be aware of this case.) > > > > Having said the above, it is up to the "collective" and not me and, as > such, > > I suggest #1, to see whether others think doing a non-Linux compatible > > version makes sense for FreeBSD? > > I believe that allowing devfs nodes for vn_copy_file() is not very good > idea. For /dev/null driver returns EOF, but think about real devices or > even better, /dev/zero that never EOF its output. > > Is vn_copy_file() interruptible ? I think not. So if insane range is > specified, we have unstoppable copier that fills the disk (at best). > I can think of good use cases for copy_file_range on a device: 1) Network block devices. I don't know if the iSCSI, NBD, or Ceph RBD protocols currently support server-side copies, but it's reasonable that they might. If they ever do, FreeBSD would need copy_file_range to take advantage. 2) CUSE. I think Linux's CUSE already supports copy_file_range, since a CUSE device on Linux is basically just a single-file FUSE file system. We might add support to our CUSE driver someday. 3) zvols. This is the use case that matters the most to me. I have a large amount of data stored in plain files that I would like to convert to zvols. dd should be able to do that using copy_file_range. In my opinion, the utility of those cases outweighs the risk of a long-running interruptible syscall. And in any case, it is documented that copy_file_range may return EINTR. -Alan