Date: Wed, 23 Sep 2020 21:21:35 +0200 From: Alexander Leidinger <Alexander@leidinger.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) Message-ID: <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> In-Reply-To: <20200923145615.GH2570@kib.kiev.ua> References: <CAOtMX2iFZZpoj%2Bap21rrju4hJoip6ZoyxEiCB8852NeH7DAN0Q@mail.gmail.com> <YTBPR01MB39666188FC89399B0D632FE8DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2gMYdcx0CUC1Mky3ETFr1JkBbYzn17i11axSW=HRTL7OA@mail.gmail.com> <YTBPR01MB3966C1D4D10BE836B37955F5DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2jHMRD0Hno03f2dqjJToR152u8d-_40GM_%2BBvNPkN_smA@mail.gmail.com> <YTBPR01MB3966BA18F43F7B6353171E67DD380@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kostikbel@gmail.com> (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 <rmacklem@uoguelph.ca> (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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani>