[QUESTION] Are Existing Directories Deleted When PV Is Deleted?

[squat]

Question

What help did you want: I have an existing JuiceFS volume with existing data in it. I have pods in different namespaces that all need access to the existing data, e.g. /existing/data. I cannot manually create the PVs and statically bind them to PVCs because there are too many PVCs and they are created dynamically for ephemeral workloads. I need to dynamically provision PVs for the PVCs in different namespaces so I want to create a StorageClass with a pathPattern that points to /existing/data.

What happens to the directory /existing/data when I delete the ephemeral Pod+PVC+PV? I am worried that the CSI driver will delete my existing data if I delete the dynamically provisioned PVs.

Environment:

• JuiceFS CSI Driver version (which image tag did your CSI Driver use): latest
• Kubernetes version (e.g. kubectl version): 1.26
• Object storage (cloud provider and region): gcs
• Metadata engine info (version, cloud provider managed or self maintained): n/a
• Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage): n/a
• Others:

[squat]

I saw: https://github.com/juicedata/juicefs-csi-driver/issues/540. This ensures that if the StorageClass specifies a pathPattern then the directory will not be deleted until the last PV that references is is deleted.

However this does not say what happens when the CSI driver did not create the directory. What if we are using existing data? Will the CSI driver still delete the directory after the final PV is deleted? This is dangerous.

[zxh326]

I saw: #540. This ensures that if the StorageClass specifies a pathPattern then the directory will not be deleted until the last PV that references is is deleted.

However this does not say what happens when the CSI driver did not create the directory. What if we are using existing data? Will the CSI driver still delete the directory after the final PV is deleted? This is dangerous.

Yes, it will be deleted, It is unclear whether the directory was created by CSI or if it already exists.

[squat]

What can be done to work with existing directories to prevent data from being deleted?

[zxh326]

What can be done to work with existing directories to prevent data from being deleted?

You can try using the static pv with subdir

static pv will not delete data

[zxh326]

docs: https://juicefs.com/docs/csi/guide/pv/#mount-subdirectory

[squat]

Yes, I read that before. As I mentioned in the first message, we create and delete lots of PVs for different namespaces all the time and it's impractical to manage them statically.

So there's no way to dynamically provision PVs and no delete data?

That seems very arbitrary! Why should statically created PVs behave one way and dynamic ones another?

I would like to make a feature request to unify the behavior of the the two different provisioning methods. This could be done with a feature flag or an option in the StorageClass configuration.

If you would accept this PR, I can contribute this.

[zxh326]

Yes, I read that before. As I mentioned in the first message, we create and delete lots of PVs for different namespaces all the time and it's impractical to manage them statically.

So there's no way to dynamically provision PVs and no delete data?

That seems very arbitrary! Why should statically created PVs behave one way and dynamic ones another?

I would like to make a feature request to unify the behavior of the the two different provisioning methods. This could be done with a feature flag or an option in the StorageClass configuration.

If you would accept this PR, I can contribute this.

please feel free to submit a pull request

[h0hmj]

1. create StorageClass with reclaimPolicy: Retain and pathPattern: "${.pvc.labels.foo}"
2. create pvc with label foo: dir1 refers to /dir1
3. create pod using this pvc

pvc creation: will reuse existed path /dir1 pvc deletion: retain data of existed path

i have simple test. it should work. does this help? but it may hard to reuse path like /dir1/dir2

cc @zxh326 @squat

[squat]

Hi @h0hm,j what is the special difference here compared to what is in the docs? Is it the reclaim policy?

So if I configure my storage class like this and delete the PVC after deleting the pod, then the data will remain in my volume?

What about if I later manually delete the PV? Will JuiceFS delete the data then?

[zxh326]

Hi @h0hm,j what is the special difference here compared to what is in the docs? Is it the reclaim policy?

So if I configure my storage class like this and delete the PVC after deleting the pod, then the data will remain in my volume?

What about if I later manually delete the PV? Will JuiceFS delete the data then?

JuiceFS will respect k8s reclaim policy

so it will only delete data when it is set to Delete

[squat]

@zxh326 thanks for that detail. So @h0hmj's example works because of the reclaim policy.

If I manually delete the PV, will the JuiceFS CSI driver delete the underlying data?

[zxh326]

@zxh326 thanks for that detail. So @h0hmj's example works because of the reclaim policy.

If I manually delete the PV, will the JuiceFS CSI driver delete the underlying data?

check pv reclaim policy, If it's Delete then delete, otherwise do nothing