We are seeing an issue at KIT where cp will occasionally use the FIEMAP extension to create a completely sparse file instead of actually copying the file. It seems to occur under a workload involving creating and deleting many files at once. It only involves a single client though, it's not a parallel workload.
Relevant strace from 'bad' cp:
ioctl(3, 0xc020660b, 0x7fff392c0950) = 0
ftruncate(4, 12853) = 0
strace from 'good' cp:
read(3, "#!/bin/bash -u\n\n#localisation\nex"..., 2097152) = 12853
write(4, "#!/bin/bash -u\n\n#localisation\nex"..., 12853) = 12853
read(3, "", 2097152) = 0
The strace didn't print the stat block information, but I'm assuming the st_blocks == 0 in the bad one. I will ask the customer to get a full strace -v to confirm, but it appears to be something similar to LU-417?
Bug
Blocker
