From owner-svn-src-head@freebsd.org Sun Sep 20 15:21:34 2020 Return-Path: Delivered-To: svn-src-head@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 6ED823E4F50; Sun, 20 Sep 2020 15:21:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670043.outbound.protection.outlook.com [40.107.67.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvWWL0c9wz3RQR; Sun, 20 Sep 2020 15:21:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lm2uFckpQ+x4JIuHFa/TTKZbANxSBv2zkxACK/ven0PI8r4mmEPtzr5q9zGPIQxLYepOy6o1pCTTatfXDEehqB5igLM0ZnRpdD+fj1dJfZh4t2KQ3bHGJeNfldvNKJzqBCcShnXCon4a0mq9mAkpPlKS4IiLeEZkTHWk6HregBZgI26k+TmypjvDBoMOSc2TOeFD2ou5jYjQgQylfLXv5ZNNFTGf9r3L486Um+3V0E14peDEqNZAD0Z2FFjVsuIU/syJDeAnd7AHinnIS+zgy8IYqsTw3wiTmW/OBxhZT7UbTrNwObCZcd5kkNdmlQGRscVsr0Tr2zZF0laSMfWfJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CRN+hO1S1wvsxcv+w504VCPhAJcNLyIgpZhktRqu5Sc=; b=a/8j7m6V9gbvKJB0kKR1OUjKYi1PcTAwtOsoMim0jwwCqP6KDkXagTt46STFMR3zNxCyC+TRnqwY6WzWK6ul/7cBHJdZxVERIIlLlOaSZ3/r8lde1Fc21nuEUZQL5XxO+/YHXyFCN6KINWW+yucaVgRQyI3ebdyDvgUy5Ayt7f78bs4v3T+MH2PDRKDC0Hm28fu8QMgHOkICiF9i7B3j3yRh+OYrwLSqoCIaZFThMTBvlF9xzgiBGKDmn7akwbXzRM3WNN24bO5Lnxp8u3yzHyRIw3tgw1cVFSbNXV8iP4DND7nhtz0ou7hRBzqS9GRn/Qrm2lAlY7P0lyAhbaXOZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CRN+hO1S1wvsxcv+w504VCPhAJcNLyIgpZhktRqu5Sc=; b=fMGh9XILrJQwuitkUnXc90GXZVAdQ1Bh1gBw1PvQdkyGkR3yqG4vmtpXbB212Q7ZaX89FQPyp5NH0COfX0KE+4PnMqcTct95P4uQ5m8Zt0TcSaRvTsRxa+O/jDhb4wfJqqUeRgByJeCj4d6vbkx1Gyu2jOM8l4SCAOnUEoHwgRZFry5wYuTNbxWBMtXAp/Fw4Pl/WkF+oZUVByrEMNJ+HqmIIkxYE0uCuZSnxjUS2Md9KqTjJlJSHJRyl/Ae4V16ZmZkU9BZ2vJEjww8ITvXAYYsfyYtdleTS6bA5aq4XsFt9vVLPRqbihM6Rhgj3QznO/PVUYwtjnyLJ2yc2+WDVA== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2938.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Sun, 20 Sep 2020 15:21:31 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.014; Sun, 20 Sep 2020 15:21:31 +0000 From: Rick Macklem To: Alan Somers , Konstantin Belousov CC: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r365643 - head/bin/cp Thread-Topic: svn commit: r365643 - head/bin/cp Thread-Index: AQHWiH0X8pBOJ1Dd2EKX5zw9++b1Talj+C+AgAABEqiADFMkAIAAVZ6LgAAHTQCAADDIAIAA08v2 Date: Sun, 20 Sep 2020 15:21:31 +0000 Message-ID: References: <202009112049.08BKnavL032212@repo.freebsd.org> <20200911214327.GY94807@kib.kiev.ua> <20200919233232.GC94807@kib.kiev.ua>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6467992b-dbea-44e6-362d-08d85d78da66 x-ms-traffictypediagnostic: YT1PR01MB2938: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hoVebZ4bo+gAVWepmmZlInq0scR6NATAMgZkAH0JYGJ0lppDWJKBT5tD/JslIiYIL+4EEhvGByE0YkJD0hLOzfT2DRPJHglKHsI/1pcB4DfewVp3AAo1OyzC+VQyYm5ED1NpFEzjwfrFpwIz5YvxINZ7kXRxDy6P9MYLozfte0/mORR51UpveudmxwFlFFXTmeQt18YpE+sv0f4C4dNzIW6y3zj3+cMJc/hYnCLLKgzQmO4IsQjrizKO6S/S+ucdGyuCoXpZoxFhCTwoDhPEjylP4jWA3pfJz0zGD+WfIw+L2wTWVmVwkJ4R3OGUfelle4/LlanfoL0ff6ZHzErDxuUYNkRXxXhatCrCLnAtmofQCLnJuJV06aGD9eY0gLZwfqfW8BZowzmxW9wM+Evyzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(396003)(39850400004)(346002)(376002)(366004)(478600001)(786003)(9686003)(83380400001)(8936002)(2906002)(6506007)(316002)(186003)(33656002)(8676002)(110136005)(54906003)(66946007)(86362001)(5660300002)(76116006)(4326008)(55016002)(7696005)(66556008)(91956017)(64756008)(66476007)(71200400001)(52536014)(66446008)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: g+RAm9LmhBVTuBKVrjIhjjaMunN3f7VAaAO+JQHDTglCzv12EPqa7ROqTKJB7Uc4hVtZ9MWZpZI5v590tgQnKdm65RN9jx28TOnCY/eGlgIC7RnBs/FZFRUtLkuybxxWOLs7jEeU2VvbtFJ6k7Osv54a4y2SJv9+j65XA3xWmmcsbNnKCQGE0LtvyX+j/bvqXGm08LKN99X2m/caYZXWVxw/+PF9Vf7KNxirzBQ3A97fadFOCHqRiQ1Yzx9bIki46XdYe7XZWuYk2RdahHk9ixAxzP8G4xWym6O19WTYgC35aXAZKywPwwPwwYLSqExM8QiBMSnfAGTnbTxjrM1Kc4MOjW1NP/TXrdNxqf+pwu81M5kD+A3bk0S7zc9pPP/oNZoQBUPHuh/xavPtKqoSBgjJRF++3Sei1uulXs4PuaFOppWAdoknjO0nMHFNwIGQj0mmG59xoKYzVBviFT+kW6loqAtEcSbdds50/BPKw/PTX3Zgi6E4FI73U+nEqVxz4XPhpPzv0DfWGp0qroQSWKq7Fkw55KiDN2bx//0V/FKnqWeOtoBXtNgj+LdMFoGTmWKbfvH1OtjtPg89xL5zpydXnnaY6nJmlirPejqvJz+Dp/x+PvGm8uvf9s4rZ0qdHgVbj7DPcpA4uxvLspETUTVwZlPPKm0u340G99OTvnceSSV0F4FMJgBaJiGDosxMTEl/odQHcwCDPVVv3vL5uQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6467992b-dbea-44e6-362d-08d85d78da66 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2020 15:21:31.3885 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MOU+uvKRkIx5OVIvlBCM6ed3Pb+xUestJoQiX7LP17vIyg/QzaeBooWjRcj/cwIP8NOl14AYFW63DjHjwEaV8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2938 X-Rspamd-Queue-Id: 4BvWWL0c9wz3RQR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; REPLY(-4.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 15:21:34 -0000 Alan Somers wrote:=0A= >On Sat, Sep 19, 2020 at 5:32 PM Konstantin Belousov > wrote:=0A= >On Sat, Sep 19, 2020 at 11:18:56PM +0000, Rick Macklem wrote:=0A= >> Alan Somers wrote:=0A= >> >On Fri, Sep 11, 2020 at 3:52 PM Rick Macklem >> wrote:=0A= >> >Konstantin Belousov wrote:=0A= >> >>On Fri, Sep 11, 2020 at 08:49:36PM +0000, Alan Somers wrote:=0A= >> >>> Author: asomers=0A= >> >>> Date: Fri Sep 11 20:49:36 2020=0A= >> >>> New Revision: 365643=0A= >> >>> URL: https://svnweb.freebsd.org/changeset/base/365643=0A= >> >>>=0A= >> >>> Log:=0A= >> >>> cp: fall back to read/write if copy_file_range fails=0A= >> >>>=0A= >> >>> Even though copy_file_range has a file-system agnostic version, it= still=0A= >> >>> fails on devfs (perhaps because the file descriptor is non-seekabl= e?) In=0A= >> >>> that case, fallback to old-fashioned read/write. Fixes=0A= >> >>> "cp /dev/null /tmp/null"=0A= >> >>=0A= >> >>Devices are seekable.=0A= >> >>=0A= >> >>The reason for EINVAL is that vn_copy_file_range() checks that both in= and out=0A= >> >>vnodes are VREG. For devfs, they are VCHR.=0A= >> >=0A= >> >I coded the syscall to the Linux man page, which states that EINVAL is = returned=0A= >> >if either fd does not refer to a regular file.=0A= >> >Having said that, I do not recall testing the VCHR case under Linux. (i= e. It might=0A= >> >actually work and the man page turns out to be incorrect?)=0A= >> >=0A= >> >I will test this case under Linux when I get home next week, rick=0A= >> I'll admit I haven't tested this in Linux to see if they do return EINVA= L.=0A= >>=0A= >> >Since there's no standard, I think it's fine for us to support devfs if= possible.=0A= >> 1 - I think this is a good question for a mailing list like freebsd-curr= ent@.=0A= >> 2 - I see Linux as the de-facto standard these days and consider POSIX n= o=0A= >> longer relevant, but that's just mho.=0A= >> 3 - For NFSv4.2, the Copy operation will fail for non-regular files, so = if you=0A= >> do this, you will need to handle the fall-back to using the generi= c code.=0A= >> (Should be doable, but you need to be aware of this case.)=0A= >>=0A= >> Having said the above, it is up to the "collective" and not me and, as s= uch,=0A= >> I suggest #1, to see whether others think doing a non-Linux compatible= =0A= >> version makes sense for FreeBSD?=0A= >=0A= >I believe that allowing devfs nodes for vn_copy_file() is not very good=0A= >idea. For /dev/null driver returns EOF, but think about real devices or= =0A= >even better, /dev/zero that never EOF its output.=0A= >=0A= >Is vn_copy_file() interruptible ? I think not. So if insane range is=0A= >specified, we have unstoppable copier that fills the disk (at best).=0A= I think this is a serious problem, but the code could clip the "len" argume= nt=0A= at K Mbytes for non-VREG files to avoid it (and document that FreeBSD=0A= specific behaviour in the man page).=0A= =0A= >I can think of good use cases for copy_file_range on a device:=0A= >=0A= >1) Network block devices. I don't know if the iSCSI, NBD, or Ceph RBD pro= tocols >currently support server-side copies, but it's reasonable that they= might. If they >ever do, FreeBSD would need copy_file_range to take advan= tage.=0A= >2) CUSE. I think Linux's CUSE already supports copy_file_range, since a C= USE >device on Linux is basically just a single-file FUSE file system. We = might add >support to our CUSE driver someday.=0A= >3) zvols. This is the use case that matters the most to me. I have a lar= ge amount >of data stored in plain files that I would like to convert to zv= ols. dd should be able >to do that using copy_file_range.=0A= >=0A= >In my opinion, the utility of those cases outweighs the risk of a long-run= ning >interruptible syscall. And in any case, it is documented that copy_f= ile_range may >return EINTR.=0A= I believe that the only case where EINTR would be returned is for NFS mount= s=0A= with the "intr" option.=0A= The generic code uses vn_rdwr()->VOP_READ()/VOP_WRITE() and I think the=0A= behaviour w.r.t. signal handling is the same as read(2)/write(2).=0A= =0A= Is reducing the number of syscalls really going to speed up the above cases= ?=0A= (I did copy_file_range(2) because the copy could be done locally on the NFS= v4.2=0A= server. I didn't intend the generic code to be used over read(2)/write(2) = to=0A= improve performance.)=0A= --> I'd suggest you try benchmarking a pre-patched vs current "cp" to copy= =0A= regular files (not a NFSv4.2 mount) and see if there really is a sign= ificant=0A= benefit.=0A= =0A= I'll admit I would prefer a Linux-compatible syscall and think this should= =0A= be asked on an open mailing list instead of here.=0A= =0A= rick=0A= =0A= -Alan=0A= =0A=