On Mon, Dec 4, 2023 at 10:38 AM Christoph Hellwig <hch@xxxxxx> wrote: > > On Mon, Dec 04, 2023 at 09:37:33AM +0100, Christoph Hellwig wrote: > > > put_rd_wr_caps(src_ci, src_got, dst_ci, dst_got); > > > - ret = do_splice_direct(src_file, &src_off, dst_file, > > > - &dst_off, src_objlen, flags); > > > + ret = splice_file_range(src_file, &src_off, dst_file, &dst_off, > > > + src_objlen); > > > > Shouldn't ceph be switched to use generic_copy_file_range? > > That does the capping of the size which we want, and doesn't update > > the file offsets, which would require recalculation in the ceph code. > > IDK. I did not want to change the logic of the ceph code. I am not sure that we must impose MAX_RW_COUNT limit on ceph, although, i_layout.object_size may already be limited? Jeff? > > But this could avoid another exported API as splice_file_range could > > simply be folded into generic_copy_file_range which should reduce > > confusion. And splice really is a mess for so many different layers > > of the onion being exposed. I've been wanting to reduce some of that > > for a while but haven't found a really nice way yet. > > (and generic_copy_file_range really should be renamed to > splice_copy_file_range and moved to splice.c) That depends if we are keeping two helpers. One with a cap of MAX_RW_COUNT and one without. If we are going to keep two helpers, I'd rather keep things as they are. If one helper, then I personally prefer splice_file_range() over splice_copy_file_range() and other reviewers (Jan) liked this name as well. Thanks, Amir.
