gcsfuse VS goseaweedfs

It uses FUSE and there's three types of Kernel cache you could use with FUSE (although, it seems like gcsfuse is exposing only one):

1. Cache of file attributes in the Kernel (this is controlled by "stat-cache-ttl" value - https://github.com/GoogleCloudPlatform/gcsfuse/blob/7dc5c7ff...)

You're looking at Filestore because your software can only write to a mounted file system? If so, you could mount a Google Cloud Storage bucket with Fuse. I haven't used Fuse myself in production, but it may be worth trying out for your workload.

Is this the same gcsfuse that's been around for years, only now with official Google support?

https://github.com/GoogleCloudPlatform/gcsfuse

I'm pretty sure the storage for a stopped VM vs a disk image will be the same. Cheaper if you can store your data in GCS bucket? Take a look at GCS-Fuse to mount storage buckets into a VM.

Currently being tracked here: https://github.com/GoogleCloudPlatform/gcsfuse/issues/961

You can check SeaweedFS https://github.com/chrislusf/seaweedfs

ChubaoFS - distributed file system and object storage Longhorn - Cloud-Native distributed block storage built on and for Kubernetes OpenEBS - Kubernetes native - hyperconverged block storage with multiple storage engines Rook - Storage Orchestration for Kubernetes SeaweedFS - Distributed file system supports read-write many volumes TiKV - Distributed transactional key-value database velero - Backup and migrate Kubernetes applications and their persistent volumes Vitess - Vitess is a database clustering system for horizontal scaling of MySQL kaDalu - A lightweight Persistent storage solution for Kubernetes / OpenShift using GlusterFS in background

seaweedfs - SeaweedFS is a simple and highly scalable distributed file system for small files.

Seaweedfs looks quite promising but its public url uuid is in the form of <32-bit volume, 64-bit file key, 32-bit file cookie>. The volume is probably fixed most of the time, the file key is an incrementing number while the file cookie is random. 32-bit seems too small to prevent guessing.

MinIO team care about an issue if you are paid customer, not for people who use the open source. Indeed MinIO is not even fully S3 compatible with many edge cases and close the issues related to it by saying it’s not a priority.

You might want to look at other options as well like SeaweedFS [0] a POSIX compliant S3 compatible distributed file system.

[0] https://github.com/chrislusf/seaweedfs

SeaweedFS is a fast, distributed storage system for blobs, objects, files and data that stores/serves billions of files. Can transparently integrate with the cloud with both fast local access and elastic cloud storage capacity. Blob store has O(1) disk seek, local and cloud tiering. Filer supports cross-cluster active-active replication, Kubernetes, POSIX, S3 API, encryption, Erasure Coding for warm storage, FUSE mount, Hadoop and WebDAV. chrislusf finds "it is much faster than the 'high performance' Minio."

welcome to help with https://github.com/chrislusf/seaweedfs

(I work on SeaweedFS) How about using SeaweedFS? https://github.com/chrislusf/seaweedfs

With your dedicated server, the latency is consistent, No API/network cost. Extra data can be tiered to S3.

Basically it is a key-file store.

https://github.com/chrislusf/seaweedfs/wiki/Filer-as-a-Key-L...

https://github.com/chrislusf/seaweedfs/wiki/Cloud-Tier

I am working on SeaweedFS. But seriously, use http://github.com/chrislusf/seaweedfs