From owner-freebsd-hackers@freebsd.org Wed Sep 23 19:21:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 61CD7424513 for ; Wed, 23 Sep 2020 19:21:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxSj73mylz4DH6 for ; Wed, 23 Sep 2020 19:21:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165e4a.dip0.t-ipconnect.de [91.22.94.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id B7F13957; Wed, 23 Sep 2020 21:21:38 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id C03F67083; Wed, 23 Sep 2020 21:21:35 +0200 (CEST) Date: Wed, 23 Sep 2020 21:21:35 +0200 Message-ID: <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> From: Alexander Leidinger To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) References: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua> In-Reply-To: <20200923145615.GH2570@kib.kiev.ua> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_cra2yUFAAPzMYOEMsTpbEue"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4BxSj73mylz4DH6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.05)[-1.046]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.015]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(0.35)[0.346]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.94.74:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 19:21:48 -0000 This message is in MIME format and has been PGP signed. --=_cra2yUFAAPzMYOEMsTpbEue Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Konstantin Belousov (from Wed, 23 Sep=20=20 2020=2017:56:15 +0300): > On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via=20=20 >=20freebsd-hackers wrote: >> Quoting Rick Macklem (from Wed, 23 Sep 2020 01:18= :18 >> +0000): >> >> > Well, I ran some quick benchmarks using the attached programs,=20=20 >>=20plus "cp" both >> > before and with your copy_file_range() patch. >> > copya - Does what I think your plan is above, with a limit of 2Mbytes >> > for "len". >> > copyb -Just uses copy_file_range() with 128Mbytes for "len". >> > >> > I first created the sparse file with createsparse.c. It is admittedly = a >> > worst case, >> > creating alternating holes and data blocks of the minimum size=20=20 >>=20supported by >> > the file system. (I ran it on a UFS file system created with defaults, >> > so the minimum >> > hole size is 32Kbytes.) >> >> Not related to the topic of changing cp, but related to the topic of >> copy_file_range: does nullfs support (as in pass-through to the underlyi= ng >> FS) copy_file_range? > > Nullfs bypasses VOP_COPY_FILE_RANGE() same as any other multi-vp arg > VOP. What makes you think it is different ? I understand "bypass" as "does not handle copy_file_range". And from=20=20 what=20I was understanding in this discussion, each FS-driver needs to=20= =20 be=20modified to support copy_file_range. I've never looked into the=20=20 nullfs=20code (and VFS is for me some kind of object oriented interface=20= =20 into=20which FSes can plug into, with a generic "I can't do that" for=20=20 parts=20of the interface which needs a FS specific implementation in=20=20 case=20the FS doesn't provide this part), so I do not know how it=20=20 handles=20the "place A is a portal into place B". Naivly speaking I=20=20 would=20assume it translates a request for a specific path by modifying=20= =20 the=20path internally, but for that it needs to provide an. I do not=20=20 know=20how much meta-data needs to be handled / kept in memory /=20=20 generated=20for this. I had the options "maybe to much for a=20=20 pass-through",=20and "maybe not too much for a pass-through". To me it=20= =20 makes=20sense, that nullfs is able to handle this (I have a samba server=20= =20 in=20a jail which has some datasets mounted via nullfs, and the same=20=20 datasets=20are also mounted into other jails and served read-only via a=20= =20 webserver=20or other kinds of servers, and would be usefule if samba=20=20 could=20use copy_file_range on nullfs). You could argue that my question=20= =20 was=20more "is nullfs modified to handle copy_file_range", than "does it=20= =20 technically=20pass-through". Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_cra2yUFAAPzMYOEMsTpbEue Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfa6A+AAoJEBINsJsD+NiG8FYQAIwJbnPLEpiKEhodr1Q36dpe LThlkX6JMEOI19PbEUBV/RPDq+vxR7cQtCrLtZXBtBhqC8zBXamCZsWC9AR7035w ZzHJXJJ+LzqmzA09X4Fo3+vPetX5rJP9HPLucDNcBXvzdv6O7mAxCcbAj/ZVuR0Z VMunq0uKz8ASutJtH65nemFTBWts665xK/7uzR0LO1MEiYxICa7Oreacu+pq0Ltt 5dZACMQgmVkYdrN/6jdGQWW7CHlgJ5NZtccAigIRLve4Y+phwhlAHxSZk0Lin7HF YKiEK/+2f32emdo8ezlFtXqO2SGHen1ZepBw2evjdwKl215E/nwh565nuIZOEknX Fp0JFY3h8tIXdY+cWPI99npM5eI7cDrOv4+bKt/Hf4+xTZde/kDrpTEagJXtlO95 g8dM3Xyw42MYtD3FHuJhWCT+IaDJZHIJd5iEDDO0uWAuHgQNazln0QAxW81KL5wJ fQG2HEmqFAr/GQXqzEpnPytcpl2n+Z3PeKNz6rEmWiwtzbrZuTyeRi9YZeafPCZF wK3EZIAdatHNjk2ukiUwvJ1ZSoTb6+QppXCkskzhBj/l98armTGpD+JrKRDgt3cu eK71XaBjrgSMb2ZQApVaoYMHA5jgyR1/OdukvIqQuQsBkN9lqqxqv3tmf5u2pRfv dnO8TGMF9rKKrBfjM1QW =3pKN -----END PGP SIGNATURE----- --=_cra2yUFAAPzMYOEMsTpbEue--