Bug 1840284 - Ruby 2.6 copy_file_range() [NEEDINFO]
Summary: Ruby 2.6 copy_file_range()
Status: CLOSED DUPLICATE of bug 1783554
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: rh-ruby26
Version: rh-ruby26
Hardware: x86_64
OS: Linux
Target Milestone: alpha
: 3.6
Assignee: ruby maint
QA Contact: RHEL CS Apps Subsystem QE
: 1840254 (view as bug list)
Depends On: 1783554
TreeView+ depends on / blocked
Reported: 2020-05-26 16:58 UTC by Marko Bevc
Modified: 2020-06-24 16:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-06-24 16:03:40 UTC
Target Upstream Version:
vondruch: needinfo? (rvrbovsk)

Attachments (Terms of Use)

Description Marko Bevc 2020-05-26 16:58:49 UTC
Description of problem:
Seems like CentOS/RHEL 7.8 has removed support for copy_file_range() and just a recompile of Ruby packages on that system would detect this and use correct underlying system calls.

How reproducible:
Try copy file using FileUtils.cp() on NFS.

Actual results:
ERROR -- [Error::CopyFileError] Operation not supported - copy_file_range

Expected results:
Copied file.

Additional info:

Comment 2 Marko Bevc 2020-05-26 17:00:06 UTC
*** Bug 1840254 has been marked as a duplicate of this bug. ***

Comment 3 Vít Ondruch 2020-05-29 11:38:51 UTC
Hi Marko,

Thx for the report. I am afraid that the solution for the problem won't be as easy as just rebuild for various reasons. I think the only solution would probably be to revert the upstream patch:


I also wonder what is your use case and how severe this is?

Anyway, could you please contact Red Hat support, so we can properly asses the priority?

Comment 5 Marko Bevc 2020-05-29 12:24:43 UTC
Hi Vit.

Perhaps I misunderstood upstream patch, shouldn't it automatically detect if this is available and fall back to previous method on 7.8? Sorry if being completely off here :)

Well we have an app in production that is failing to run due FileUtils.cp() is failing to copy local->NFS files. Our workaround was to revert to latest 7.7 kernel to get around it.

Unfortunately we're not a RH customer and we are using CentOS and SCL Ruby 2.6.

Happy to provide more infromation if needed and hope we can escalate this as it seems to be breaking Ruby 2.6 on RH/CentOS 7.8 now.


Comment 6 Eric Sandeen 2020-05-29 13:48:24 UTC
There's very little to go on in this bug report.

Under which kernel version do you see this error?

Can you provide a Ruby testcase that demonstrates the error?

Comment 7 Marko Bevc 2020-05-29 17:01:18 UTC
It's latest kernel in 7.8 release: 3.10.0-1127.8.2.el7

Of course, it's actually copying from NFS to NFS:

require "fileutils"

FileUtils.cp "source.txt", "source_copy.txt"

# rh-ruby26-run ./range.rb
Traceback (most recent call last):
        12: from /mnt/bluetack/copy_file_range/range.rb:3:in `<main>'
        11: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:418:in `cp'
        10: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1555:in `fu_each_src_dest'
         9: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1573:in `fu_each_src_dest0'
         8: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1557:in `block in fu_each_src_dest'
         7: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:419:in `block in cp'
         6: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:492:in `copy_file'
         5: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1385:in `copy_file'
         4: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1385:in `open'
         3: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1386:in `block in copy_file'
         2: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1386:in `open'
         1: from /opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1387:in `block (2 levels) in copy_file'
/opt/rh/rh-ruby26/root/usr/share/ruby/fileutils.rb:1387:in `copy_stream': Operation not supported - copy_file_range (Errno::ENOTSUP)

Please let me know if there is anything else I can provide to make it easier to reproduce and fix.

Thank you!

Comment 10 Eric Sandeen 2020-06-01 15:31:46 UTC
It looks to me like ruby is not handling ENOTSUP / EOPNOTSUP:

copy_file_range(5, NULL, 6, NULL, 7, 0) = -1 EOPNOTSUPP (Operation not supported)


This behavior seems unique to NFS; works fine on a local XFS volume, which returns ENOSYS:

copy_file_range(5, NULL, 6, NULL, 7, 0) = -1 ENOSYS (Function not implemented)

It's coming from:

int nfs42_proc_clone(struct file *src_f, struct file *dst_f,
                     loff_t src_offset, loff_t dst_offset, loff_t count)
        struct rpc_message msg = {
                .rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_CLONE],
        struct inode *inode = file_inode(src_f);
        struct nfs_server *server = NFS_SERVER(file_inode(src_f));
        struct nfs_lock_context *src_lock;
        struct nfs_lock_context *dst_lock;
        struct nfs4_exception src_exception = { };
        struct nfs4_exception dst_exception = { };
        int err, err2;

        if (!nfs_server_capable(inode, NFS_CAP_CLONE))
                return -EOPNOTSUPP;

Bruce, looks like another item in the CFR saga for RHEL7?

Comment 11 J. Bruce Fields 2020-06-01 15:36:00 UTC
This looks like bug 1783554

Comment 12 Marko Bevc 2020-06-01 15:38:32 UTC
Cannot see https://bugzilla.redhat.com/show_bug.cgi?id=1783554 as it's internal one, but glad to hear you were able to replicate it and aware of this.

Comment 14 Vít Ondruch 2020-06-01 15:51:01 UTC
(In reply to J. Bruce Fields from comment #11)
> This looks like bug 1783554

Ah, if that is the case, I'd be glad if this was closed as duplicate, since this will very likely hit not just Ruby.

Comment 16 J. Bruce Fields 2020-06-01 18:35:53 UTC
(In reply to Marko Bevc from comment #12)
> Cannot see https://bugzilla.redhat.com/show_bug.cgi?id=1783554 as it's
> internal one

Thanks, that should be fixed now.

Comment 18 Marko Bevc 2020-06-01 18:44:42 UTC
Thanks, there is reference to https://bugzilla.redhat.com/show_bug.cgi?id=1736794 which is also locked?

btw, is there an ETA or known solution for this one perhaps?


Comment 19 Vít Ondruch 2020-06-02 07:05:28 UTC
(In reply to Marko Bevc from comment #18)
> btw, is there an ETA or known solution for this one perhaps?

The bug 1783554 was unlocked as far as I can tell, you should be able to see more information there.

Comment 20 Marko Bevc 2020-06-02 09:04:00 UTC
It references https://bugzilla.redhat.com/show_bug.cgi?id=1736794 as well, like posted ^^

Hope we can sort this soon and be able to use latests kernel.


Comment 21 Eric Sandeen 2020-06-02 16:59:03 UTC
A quick test of the kernel which includes fixes for bug #1783554 indicates that this issue is resolved by that bug, this can probably be duped.

Comment 22 Marko Bevc 2020-06-02 17:02:08 UTC
That's great news. Which kernel is that?

Comment 23 Marko Bevc 2020-06-04 20:10:33 UTC
Assigning not this one yet https://access.redhat.com/errata/RHBA-2020:2355 ?

Comment 24 Marko Bevc 2020-06-10 08:42:41 UTC
I mean assuming ^^ :) 

Is there kernel with fix for this out already, we can try?


Comment 25 Marko Bevc 2020-06-24 12:19:02 UTC
Do we have any progress on this issue? Thanks.

Comment 26 J. Bruce Fields 2020-06-24 16:03:40 UTC

*** This bug has been marked as a duplicate of bug 1783554 ***

Note You need to log in before you can comment on or make changes to this bug.