RFC: copy_file_range(3)

Konstantin Belousov kostikbel at gmail.com
Wed Sep 23 14:56:24 UTC 2020


On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via freebsd-hackers wrote:
> Quoting Rick Macklem <rmacklem at uoguelph.ca> (from Wed, 23 Sep 2020 01:18:18
> +0000):
> 
> > Well, I ran some quick benchmarks using the attached programs, plus "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 supported 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 underlying
> 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 ?


More information about the freebsd-hackers mailing list