You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, it seems that the view of the csi driver is that when you make a PV using an efs handle, that PV should represent the entire EFS filesystem. This means that if you create two PVs pointing to the same efs handle, both PVs will contain all files on the filesystem and a file written to one PV will show up in another.
Describe the solution you'd like in detail
This seems entirely contrary to the idea of a Volume to me. When you ask for a volume using EBS as the backing storage, this is not the behavior. The entire EBS volume is not mounted for your use. Instead, an area inside the EBS disk is reserved for pods to mount. It is expected that when you create a new PV, it will be empty and that other PVs are different volumes. Not two pointers to the same underlying volume. I would expect the EFS storage type to work the same way.
Describe alternatives you've considered
If for some reason, the current behavior is desired (it seems like the only use-case here would be sharing storage across namespaces which seems like a bad idea in general), then a mountPath could be added to the pv.spec.csi.volumeAttributes mapping. This field would allow a user to specify a particular subpath specifically for that PV. If left blank, the behavior would continue as-is unchanged.
Additional context
It may be worth noting that the efs-provisioner works in this way - PVs provisioned with it are distinct and do not share files even though they are backed by the same EFS filesystem. Users porting from the provisioner to csi will likely find this difference in behavior surprising (as I have).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, it seems that the view of the csi driver is that when you make a PV using an efs handle, that PV should represent the entire EFS filesystem. This means that if you create two PVs pointing to the same efs handle, both PVs will contain all files on the filesystem and a file written to one PV will show up in another.
Describe the solution you'd like in detail
This seems entirely contrary to the idea of a Volume to me. When you ask for a volume using EBS as the backing storage, this is not the behavior. The entire EBS volume is not mounted for your use. Instead, an area inside the EBS disk is reserved for pods to mount. It is expected that when you create a new PV, it will be empty and that other PVs are different volumes. Not two pointers to the same underlying volume. I would expect the EFS storage type to work the same way.
Describe alternatives you've considered
If for some reason, the current behavior is desired (it seems like the only use-case here would be sharing storage across namespaces which seems like a bad idea in general), then a
mountPath
could be added to thepv.spec.csi.volumeAttributes
mapping. This field would allow a user to specify a particular subpath specifically for that PV. If left blank, the behavior would continue as-is unchanged.Additional context
It may be worth noting that the efs-provisioner works in this way - PVs provisioned with it are distinct and do not share files even though they are backed by the same EFS filesystem. Users porting from the provisioner to csi will likely find this difference in behavior surprising (as I have).
The text was updated successfully, but these errors were encountered: