I don’t understand whether this is just a higher level abstraction of boto’s s3 client (à la s3fs)
Mountpoint – file client for S3 written in Rust, from AWS
91–100 of 102 posts
Re: Mountpoint – file client for S3 written in Rust, from AWS
#92Earlier quoted context omitted.
Forgive the question but I never quite understood the point of S3. It seems it’s a terrible protocol but it’s designed for bandwidth. Why couldn’t they have used something like, say, 9P or Ceph? Surely I’m missing something fundamental. EDIT: In my personal experience with S3 it’s always been super slow.
The problem is S3 is just a lexicographically ordered key value store with (what I suspect is) key-range partitions[1] for the key part and Reed-Solomon encoded blobs for the value part. In other words, it’s a glorified NoSQL database with no semantics that you’d typically expect of a file system, and therefore repeated writes are slow because any modification to an object involves writing a new version of the key al…
These aren't really problems tho, just features.
These features may or may not be a problem for your application depending on your specific requirements.
It's clear that for many many applications S3 works just fine.
If you require file system semantics or interfaces (i.e. POSIX) or you update objects a lot or require non-sequential updates or.... then maybe it's not for you.
Re: Mountpoint – file client for S3 written in Rust, from AWS
#93[dead]
Re: Mountpoint – file client for S3 written in Rust, from AWS
#94I don’t understand whether this is just a higher level abstraction of boto’s s3 client (à la s3fs)
It looks to be a completely different codebase from boto/s3fs.
Not having used s3fs I'm going to guess that s3fs is limited due to the limits of the underlying language - Python - namely poor performance overall and poor multi-thread story.
I'd imagine s3fs is useful for stuff like backing up personal projects, quickly sharing files between developers etc.
For operating at any kind of scale - in terms of concurrent requests, number or size of files etc - I'd guess that Mountpoint would be the only viable solution.
Re: Mountpoint – file client for S3 written in Rust, from AWS
#95Re: Mountpoint – file client for S3 written in Rust, from AWS
#96Re: Mountpoint – file client for S3 written in Rust, from AWS
#97This is really interesting and something I've been thinking about for a while now. The SEMANTICS[1] doc details what is and isn't supported from a POSIX filesystem API perspective, and this stands out: Write operations (write, writev, pwrite, pwritev) are not currently supported. In the future, Mountpoint for Amazon S3 will support sequential writes, but with some limitations: Writes will only be supported to new fil…
Forgive the question but I never quite understood the point of S3. It seems it’s a terrible protocol but it’s designed for bandwidth. Why couldn’t they have used something like, say, 9P or Ceph? Surely I’m missing something fundamental. EDIT: In my personal experience with S3 it’s always been super slow.
S3 works over HTTP, which means that it is designed to work over the internet.
Other protocols you mentioned, including NFS, does not work well over the internet.
Some of them are exclusively designed to work within the same network, or very sensitive to network latency.
Re: Mountpoint – file client for S3 written in Rust, from AWS
#98I want a better client for Google Cloud Storage, too, while we’re at it. The Python gcloud / gsutil stuff is mediocre on the best of days.
https://github.com/GoogleCloudPlatform/gcsfuse ?
FUSE makes everything worse, not better. The Unix file API is awful in general, and a terrible mismatch for key-values storage systems.
Re: Mountpoint – file client for S3 written in Rust, from AWS
#99Earlier quoted context omitted.
That depends on what you consider "fast". EFS (the "serverless" NFS) has sub-millisecond operation latency. S3 is more in the 10-20ms range for most operations, with occasional spikes. BTW, if you need a pure Go client for NFSv4 (including AWS EFS), feel free to check my: https://github.com/Cyberax/go-nfs-client
We can write vast numbers and volume of objects to S3 per second using concurrent processes (spawn 1000 lambda invocations and try it). As long as I have the network bandwidth, I can push stuff essentially as fast as I want. Is that true for EFS? Handle limits. Network interface limits. Protocol limits. I’m not saying that S3 is perfect or even good for most workloads. However, it is most excellent when the workload…
EFS will handle 1000 readers/writers. We tested it as a data exchange medium for computational tasks. The meta-information APIs in EFS in my experience are faster than S3's (LIST in S3 is notorious). The overall amount of data we stored in EFS was pretty limited (single-digit terabytes), though.
I wouldn't use EFS to store petabytes of data, but if you need a resilient and scalable storage that you can easily integrate into your application, then EFS is great.
One thing that I loved, is the ease of use in local development. With EFS you can simply mount the shared volume into your Docker/K8s container in production, and a local directory when you're developing tasks locally on your laptop. You can even run tasks without a container and monitor their output by looking at the exchange directory. There are AWS API emulators (e.g. Localstack) but they are not as convenient.