Comment 26 for bug 1305335

I think it is still useful for ecryptfs to support the btrfs clone ioctl for the case where both source and target higher files are in the same ecryptfs mount, since this saves disk space.

We might be able to handle this in fs/ecryptfs/file.c#ecryptfs_unlocked_ioctl, which gets passed the btrfs ioctrl clone command along with the the higher target file. It unconditionally converts it to the lower file and then passes it down to btrfs:

  struct file *lower_file = ecryptfs_file_to_lower(file);
   ...
  if (lower_file->f_op->unlocked_ioctl)
    rc = lower_file->f_op->unlocked_ioctl(lower_file, cmd, arg);

Adding code here that returns failure if the command is BTRFS_IOC_CLONE makes the cp --reflink=always command fail. (cp --reflink=auto then works because cp detects the failure and does a non-clone copy, and the same should go for the glib file copy).

However, note that:

1. When it fails to clone, ecryptfs still creates a valid but zero-byte file after the failed clone operation, so ecryptfs should probably remove this when it returns fail for the clone operation.

2. It shouldn't fail if the source and target files are both inside the same ecryptfs mount.

3. Do symlinks affect it, eg if the target is a symlink outside the ecryptfs mount that points to the higher ecryptfs file?

4. ecryptfs_compat_ioctl might possibly be affected as well since it does the same thing as ecryptfs_unlocked_ioctl.