csi-driver-smb VS juicefs

https://github.com/kubernetes-csi/csi-driver-smb. This is the CSI driver we use.

Actual media storage (movies, pictures, anything that lives on my unRAID box) is mounted to each pod that needs it via the SMB CSI driver. I would love to use NFS instead, but even with 4.x, I was running into stale file mount issues. You can see my findings and why I decided to use SMB instead here

What is the recommended way to use S3 as shared storage for media (videos)? Currently I'm using SAMBA network share RWX volumes using this plugin and I would like to switch to S3 compatible service to increase performance and to avoid my current limit set by my cloud provider on that SAMBA server of 10 active connections for SAMBA.

With SMB I'm using the CSI SMB Driver helm chart to deploy it. When creating the persistent volume I'm able to use some mounting options where I have the following included:

Kubernetes has a native solution for many different storage integrations - CSI. There is a CSI driver for SMB as well. After installing the driver you will be able to map your config files from smb server via regular volume mount and config map.

I mean, in short either find a project that includes support for it (I don't know of one), or look at a CSI that does like the SMB CSI driver.

Using a CSI Plugin you should be able to separate the admin side from the user side. I haven't dove into this but here is a plugin that might help - https://github.com/kubernetes-csi/csi-driver-smb

Look into using flex volumes (though depricated) or its successor SMB CSI driver

Support for Kerberos keytab files

JuiceFS under the Apache License 2.0, is a high-performance POSIX file system optimized for cloud-native environments. It stores data in Object Storage (e.g., Amazon S3) and metadata in databases like Redis, MySQL, or TiKV. JuiceFS integrates massive cloud storage with big data, machine learning, and AI applications efficiently, akin to local storage. It features full POSIX and Hadoop compatibility, S3 interface, Kubernetes support, and shared file storage for numerous clients. Some cool features are - strong consistency, scalable performance, data encryption, global file locks, and compression with LZ4 or Zstandard.

To improve the handling process of capacity overrun, the JuiceFS client supports deletion operations in the case of Ceph cluster fullness (see related code changes in JuiceFS Community Edition). Therefore, for newer client versions, there is no need to use set-full-ratio for temporary adjustments.

If you have any questions or would like to learn more, feel free to join discussions about JuiceFS on GitHub and the JuiceFS community on Slack.

The architecture image shows GCS and others, so I suspect it does.

https://github.com/juicedata/juicefs#architecture

See also: JuiceFS: https://juicefs.com/

Adds a DBMS or key-value store for metadata, making the filesystem much faster (POSIX, small overwrites don't have to replace a full object in the GCS/S3 backend).

Almost certainly a better solution if you want to turn your object storage into a mountable filesystem, with the (big) caveat that you can't access the files directly in the bucket (they are not stored transparently).

JuiceFS can do the same thing as s3fs-fuse, but better. Because it supports robust data consistency and caching policies to improve performance.