> This initial patch provides a callback=None parameter in case the CoW operation fails because not supported by the underlying filesystems but this is debatable because we can get different errors depending on the platform (which is not good). As such a more generic ReflinkNotSupportedError exception is probably a better choice.

(Oh, my laptop only uses btrfs. Hum, I created a loop device to test an ext4 partition :-))

On an ext4 partition, cp --reflink simply fails with an error: it doesn't fallback on a regular copy.

vstinner@apu$ dd if=/dev/urandom of=urandom bs=1k count=1k
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0123142 s, 85.2 MB/s

vstinner@apu$ cp --reflink urandom urandom2
'urandom' -> 'urandom2'
cp: failed to clone 'urandom2' from 'urandom': Operation not supported

vstinner@apu$ file urandom2
urandom2: empty
vstinner@apu$ stat urandom2
  File: urandom2
  Size: 0         	Blocks: 2          IO Block: 1024   regular empty file
Device: 700h/1792d	Inode: 13          Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/vstinner)   Gid: ( 1000/vstinner)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2019-06-05 12:08:23.000000000 +0200
Modify: 2019-06-05 12:08:23.000000000 +0200
Change: 2019-06-05 12:08:23.000000000 +0200
 Birth: -


Not only it fails, but it leaves an empty file.

I suggest to mimick the Linux cp command: don't automatically fallback (there are too many error conditions, too many risks of raising a new error while handling the previous error) and don't try to remove the created empty file if reflink() fails.