Gregory Farnum <gfarnum@xxxxxxxxxx> writes:
> On Fri, Sep 7, 2018 at 2:11 AM, Luis Henriques <lhenriques@xxxxxxxx> wrote:
>> Gregory Farnum <gfarnum@xxxxxxxxxx> writes:
>>
>>> I don't have much useful to say here (unless Zheng wants me to look
>>> carefully at the use of copy-get), but I'm excited to see this getting
>>> done! :)
>>>
>>> One thing I will note is that it might be a good idea if at least one
>>> of the system admin or the Ceph cluster admin can disable this
>>> behavior, just in case bugs turn up with the copy-from op. I don't
>>> expect any as this is a pretty friendly use-case for it (protected by
>>> FS caps, hurray!) but it is the first non-cache-tiering user that will
>>> turn up in the wild I'm aware of.
>>
>> If I understand you correctly, you're talking about adding a knob so
>> that the OSDs could simply return an error when requested to perform a
>> 'copy-from' op, right? That shouldn't be too difficult, I believe.
>
> Oh heavens no. I mean a switch on the client side to not invoke the
> copy-from op at all. Probably that would just mean doing a full read
> of the source and write of the destination, but perhaps you could also
> just unhook the copy_file_range implementation from the VFS?
>
> I would assume this is pretty trivial but if it's complicated then
> don't worry about it — I bring it up mostly because Josh thought there
> were some outstanding issues with this RADOS op but on deeper
> inspection he was wrong and conflating some other things. :)
Ah, sure! That could be done. I guess that a new mount option
('nocopyfrom'?) could be added, which would cause the ceph
copy_file_range implementation to simply fallback to the default VFS
implementation (i.e. simply do a do_splice_direct). I'll suggest
something in an extra patch in v4 of this series. Thanks!
Cheers,
--
Luis
