*** Bug 1840254 has been marked as a duplicate of this bug. ***

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:

https://github.com/ruby/ruby/commit/0686d5f4eb488d96d2688aebbdcd54e5b81eb779

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?

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.


Thanks!

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?

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:

range.rb:
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!

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)

https://github.com/ruby/ruby/blob/0686d5f4eb488d96d2688aebbdcd54e5b81eb779/io.c#L10576

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?

This looks like bug 1783554

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.

(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.

(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.

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?

Cheers

(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.

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.

Thanks!

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.

That's great news. Which kernel is that?

Assigning not this one yet https://access.redhat.com/errata/RHBA-2020:2355 ?

I mean assuming ^^ :) 

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

Thanks

Do we have any progress on this issue? Thanks.

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