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
The CSI driver currently leverages several Linux tools to implement certain low-level features, like mount for mounting / unmounting or blkid to determine if a path / file system is mounted.
We should consider moving to the Go syscall package instead which provides as least some of the functionality needed in a programmatic fashion. The benefits are that we do not depend on the availability of certain tools, and that we don't need to shell out (which complicates matters like putting together CLI parameters and properly reporting errors).
The text was updated successfully, but these errors were encountered:
In your opinion are tools built on the Go syscall implementation regularly maintained enough to keep pace with filesystems that need mount helpers, or can you envision an implementation that maintains a similar interface as mount(8) when mount helpers should be invoked?
As an intermediate step towards being less dependent on specific tools, we can increase our adoption of Kubernetes-provided utilities like https://github.com/kubernetes/mount-utils. We already use it to ease unmounting and should start looking into the mounting counterpart as well (and possibly more depending on what other functionality the library provides).
In addition to studying the library code, I have found Google's PersistentDisk CSI driver to be good source of inspiration to understand how these utilities might be best used.
The CSI driver currently leverages several Linux tools to implement certain low-level features, like
mount
for mounting / unmounting orblkid
to determine if a path / file system is mounted.We should consider moving to the Go syscall package instead which provides as least some of the functionality needed in a programmatic fashion. The benefits are that we do not depend on the availability of certain tools, and that we don't need to shell out (which complicates matters like putting together CLI parameters and properly reporting errors).
The text was updated successfully, but these errors were encountered: