[libglnx: 1/2] glnx-fdio: handle EOPNOTSUPP for copy_file_range



commit 7e3a19958e6af94b764c772a58adf47e6cc4b678
Author: Jonathan Lebon <jonathan jlebon com>
Date:   Tue Jun 16 12:29:46 2020 -0400

    glnx-fdio: handle EOPNOTSUPP for copy_file_range
    
    When using `copy_file_range` to target a source and dest on the same NFS
    mount on some older kernel versions, it's possible that we can get
    `EOPNOTSUPP` e.g. if the NFS server doesn't support server-side copy.
    
    We hit this in the FCOS release pipeline where we run `ostree
    pull-local` to pull content between two repos on the same mount from
    inside an OpenShift cluster on top of RHEL7.
    
    Nowadays, it seems like the kernel itself falls back to a more generic
    version of `copy_file_range()` at least. Though to be compatible with
    older kernels, let's add `EOPNOTSUPP` to the list of errors we interpret
    as "cfr possibly available, but can't be done for this specific
    operation".

 glnx-fdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/glnx-fdio.c b/glnx-fdio.c
index 6ae6ec7..e537a9b 100644
--- a/glnx-fdio.c
+++ b/glnx-fdio.c
@@ -826,7 +826,7 @@ glnx_regfile_copy_bytes (int fdf, int fdt, off_t max_bytes)
                   have_cfr = 0;
                   try_cfr = false;
                 }
-              else if (errno == EXDEV)
+              else if (G_IN_SET (errno, EXDEV, EOPNOTSUPP))
                 /* We won't try cfr again for this run, but let's be
                  * conservative and not mark it as available/unavailable until
                  * we know for sure.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]