RFC: copy_file_range(3)

[Alexander Leidinger]

Quoting Konstantin Belousov <kostikbel at gmail.com> (from Wed, 23 Sep  
2020 17:56:15 +0300):

> 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 ?

I understand "bypass" as "does not handle copy_file_range". And from  
what I was understanding in this discussion, each FS-driver needs to  
be modified to support copy_file_range. I've never looked into the  
nullfs code (and VFS is for me some kind of object oriented interface  
into which FSes can plug into, with a generic "I can't do that" for  
parts of the interface which needs a FS specific implementation in  
case the FS doesn't provide this part), so I do not know how it  
handles the "place A is a portal into place B". Naivly speaking I  
would assume it translates a request for a specific path by modifying  
the path internally, but for that it needs to provide an. I do not  
know how much meta-data needs to be handled / kept in memory /  
generated for this. I had the options "maybe to much for a  
pass-through", and "maybe not too much for a pass-through". To me it  
makes sense, that nullfs is able to handle this (I have a samba server  
in a jail which has some datasets mounted via nullfs, and the same  
datasets are also mounted into other jails and served read-only via a  
webserver or other kinds of servers, and would be usefule if samba  
could use copy_file_range on nullfs). You could argue that my question  
was more "is nullfs modified to handle copy_file_range", than "does it  
technically pass-through".

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20200923/5e97728b/attachment.sig>