From 7e3a19958e6af94b764c772a58adf47e6cc4b678 Mon Sep 17 00:00:00 2001 From: Jonathan Lebon Date: Tue, 16 Jun 2020 12:29:46 -0400 Subject: 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. -- cgit v1.2.1