When I was testing juiceFS to expand PV, I found that it was not effective when expanding the existing PV.

[xpnuo]

this is link about juiceFS to expand PV (https://juicefs.com/docs/zh/csi/guide/configurations/#pv-expansion)
It says here that dynamic expansion and contraction of existing PV capacity is not supported, but this scenario is very common in business testing. Are there plans to support this function in the future?

[zwwhdls]

Regarding to the official document of CSI, the secret of expanding is passed by controllerExpandSecretRef. And what csi driver received is the secret data, not secret name. request is as follows:

message ControllerExpandVolumeRequest {
  // The ID of the volume to expand. This field is REQUIRED.
  string volume_id = 1;

  // This allows CO to specify the capacity requirements of the volume
  // after expansion. This field is REQUIRED.
  CapacityRange capacity_range = 2;

  // Secrets required by the plugin for expanding the volume.
  // This field is OPTIONAL.
  map<string, string> secrets = 3 [(csi_secret) = true];

  // Volume capability describing how the CO intends to use this volume.
  // This allows SP to determine if volume is being used as a block
  // device or mounted file system. For example - if volume is
  // being used as a block device - the SP MAY set
  // node_expansion_required to false in ControllerExpandVolumeResponse
  // to skip invocation of NodeExpandVolume on the node by the CO.
  // This is an OPTIONAL field.
  VolumeCapability volume_capability = 4;
}

From the perspective of CSI, we can not select provisioner-secret or controller-expand-secret.

However, the controllerExpandSecretRef can be edited in PV. Can you run a script to add controllerExpandSecretRef in PVs by batch?