Yeah this seems to be an issue in glibc, fixed 11 days ago:
https://sourceware.org/git/?p=glibc.git;a=commit;h=7107bebf19286f42dcb0a97581137a5893c16206
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79139
Okay I managed to reproduce the issue by producing a file with enough hole and large-enough filled extents. This seems to be an interaction between zfs and glibc (and the buggy behavior seems to be in glibc from initial analysis).
If you intend...
It's a bit unexpected that the bad iso is the one with holes.
It would be interesting to see
- the file's allocation information before the copy
- how cp sees the holes.
Could you provide the following:
- The output of the breaking cp...