Describe the feature you'd like to have
Implement the CSI ControllerModifyVolume RPC in the CephFS driver to allow
pinning a CephFS subvolume to MDS ranks through the Kubernetes
VolumeAttributesClass API.
The feature exposes two mutable parameters on a VolumeAttributesClass:
mds-pin-type: the pin policy — one of export, distributed, or random.mds-pin-setting: the value for the pin (e.g. an MDS rank "2" for export,
"1"/"0" for distributed, or a float "0.0"–"1.0" for random).
This is the CSI-native equivalent of:
ceph fs subvolume pin <fs> <subvolume> <pin_type> <pin_setting>
A PVC can be pinned at creation time or re-pinned at runtime by
setting/patching its volumeAttributesClassName.
What is the value to the end user? (why is it a priority?)
In multi-MDS CephFS deployments, Ceph balances metadata subtrees across active
MDS ranks dynamically. Today Ceph-CSI users have no Kubernetes-native way to
influence this and must run ceph commands out of band, which is error-prone
and disconnected from the volume lifecycle.
With this feature, end users can, declaratively from Kubernetes:
- Improve performance for latency-sensitive workloads via MDS affinity to a
specific rank.
- Isolate specific namespaces/tenants to dedicated MDS ranks.
- Explicitly control metadata load distribution (e.g. after scaling MDS
ranks) — and change it at runtime by patching the PVC's
volumeAttributesClassName.
The concerns that closed #2637 no longer apply, and #4662 signals maintainer
interest in exactly this ControllerModifyVolume mechanism.
How will we know we have a good solution? (acceptance criteria)
TBD
Additional context
Describe the feature you'd like to have
Implement the CSI
ControllerModifyVolumeRPC in the CephFS driver to allowpinning a CephFS subvolume to MDS ranks through the Kubernetes
VolumeAttributesClassAPI.The feature exposes two mutable parameters on a
VolumeAttributesClass:mds-pin-type: the pin policy — one ofexport,distributed, orrandom.mds-pin-setting: the value for the pin (e.g. an MDS rank"2"forexport,"1"/"0"fordistributed, or a float"0.0"–"1.0"forrandom).This is the CSI-native equivalent of:
ceph fs subvolume pin <fs> <subvolume> <pin_type> <pin_setting>A PVC can be pinned at creation time or re-pinned at runtime by
setting/patching its
volumeAttributesClassName.What is the value to the end user? (why is it a priority?)
In multi-MDS CephFS deployments, Ceph balances metadata subtrees across active
MDS ranks dynamically. Today Ceph-CSI users have no Kubernetes-native way to
influence this and must run
cephcommands out of band, which is error-proneand disconnected from the volume lifecycle.
With this feature, end users can, declaratively from Kubernetes:
specific rank.
ranks) — and change it at runtime by patching the PVC's
volumeAttributesClassName.The concerns that closed #2637 no longer apply, and #4662 signals maintainer
interest in exactly this
ControllerModifyVolumemechanism.How will we know we have a good solution? (acceptance criteria)
TBD
Additional context
https://docs.ceph.com/en/latest/cephfs/multimds/#cephfs-pinning
VolumeAttributesClass(GA in v1.34):https://kubernetes.io/blog/2025/09/08/kubernetes-v1-34-volume-attributes-class