RBD: Enable support for reflink on XFS

[nixpanic]

Describe the feature you'd like to have

XFS supports reflinking that makes it possible to do copy-on-write with the copy_file_range() syscall. Not all Linux kernels support this feature, and when enabled on an RBD image, kernels without support will not be able to mount the filesystem.

Being conservative, and preventing breakage of users that migrate from Ceph Nautilus to Ceph Octopus based container images, reflink for XFS has been disabled by default (#966).

Users may want to enable reflink support on Kubernetes clusters that have current Linux kernels. The following proposed option in a StorageClass would make this possible:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   pool: rbd
   reflink: disabled|enabled|auto

Values for the new reflink option:

• disabled: detect support in mkfs.xfs, and pass -m reflink=0 if supported (default)
• enabled: force enabling, always pass -m reflink=1, will fail to mount on old Linux kernels
• auto: do nothing, do not pass -m reflink= and make this default in some next Ceph-CSI version

Additional context

See #966 for related problems.

[Madhu-1]

Thanks for opening this one. Let's track it for the next release.

[humblec]

Closing this issue as its already fixed.

[Madhu-1]

@humblec this is not fixed, this is a feature request to enable reflink, reopening it for the se reason

[Madhu-1]

@nixpanic can this be done in 3.1.0? or do we need to move it out to the next release?

[humblec]

@nixpanic please adjust the milestone accordingly.

[humblec]

Moving this from 3.1.0 considering the release timeline.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

[Madhu-1]

@nixpanic should we keep it alive or close it now and reopen if required?

[nixpanic]

I don't think we care much about reflink on RBD volumes. There have been no user requests about it, so closing it should be fine. We can always revisit if someone needs reflink on RBD volumes.