Live data from Hacker News

Amazon Elastic File System

aws.amazon.com

11–20 of 217 posts

Re: Amazon Elastic File System

#11
post #2

On the one hand, I've been wanting something like this for a while. On the other hand, I have so many bad memories of problems caused by NFS in production from the 90s that I'm leery.

At least the Linux NFS client made some big improvements in stability by the mid-2000s. FreeBSD took longer but I've heard they've fixed the kernel deadlocks as well.

The other interesting note is that they apparently only support NFSv4, which has some welcome improvements: it uses TCP over a single port, avoids the entire portmap/statd/lockd train-wreck, UTF-8 everywhere, etc. One of the more interesting ones is that it has referrals (think HTTP redirect) so one server doesn't have to handle every request from every client and you can do things like load-balancing. Clients are also assumed to be smarter so e.g. local caching is safe because the server can notify you about changes to open files rather than requiring the client to poll.

Re: Amazon Elastic File System

#12

Looks interesting... but for my use case I'd rather not deal with NFS, use a FUSE-based S3 mount and save 90%.

S3fs filesystems are really slow. We tested around 10mb/s for file upload. Where it really struggles is when you have a lot of files in a folder. Try doing an 'ls' on a folder with hundreds of files to see it break.

Re: Amazon Elastic File System

#14
post #6

Earlier quoted context omitted.

You can mount the volume on more than one instance at the same time, which you can't do with EBS.

It's also hard to resize an EBS volume, right? This resizes itself automatically.

You have to create a snapshot of the EBS volume and create a new (larger) volume from said snapshot to grow the volume. Yep, this resizes automatically.

Re: Amazon Elastic File System

#16
I wish AWS would be a little more technical in their product descriptions and announcements. If there was ever an audience that wants technical data about how this type of technology will scale and compares to existing technology like glusterfs it would be the AWS users. Instead the performance specifications are ".. and is designed to provide the throughput, IOPS, and low latency needed for a broad range of workloads." We know that NFS to a lot of nodes is hard, show us that this scales better or am I the testing team?

Re: Amazon Elastic File System

#17
post #13
post #4

We have been needing this very thing for hosting a large number of assets across multiple ec2 instances. Hope they roll this out quickly.

I believe it is to be released Summer 2015. I've applied for the Preview though.

For what it's worth, We've found that if you contact your account manager @ AWS, the preview access requests can be pushed through faster.

Re: Amazon Elastic File System

#18

I think this is a great product, but I've been actively avoiding NFS for a while now. It's a real shame that there isn't a better network FS protocol standardized already - NFS is complex, is usually a single point of failure (would be interesting to know if EFS isn't...) and comes with a whole set of cruft.

I understand why they did it, though. It's either this (everyone supports NFS, even Windows) or get crucified for vendor lock-in. Just like Github did yesterday (https://news.ycombinator.com/item?id=9343021), even when they released their product as an open standard with an open source reference implementation.

Re: Amazon Elastic File System

#19
We're contemplating moving our static image files (JPG/PNG) from an EBS volume to serving them from an S3 bucket (so we can deploy a HA setup). It sounds like it would be a lot less code if we used EFS instead. Would you guys recommend S3 or EFS for this scenario?
Post reply on HN