Amazon Elastic File System • Hacker News Board

Re: Amazon Elastic File System

#21

Post by ealexhudson » Thu, Apr 09, 2015, 6:14 PM UTC

koenigdavidmj wrote: post #18

ealexhudson wrote: post #3

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.

Well, indeed, I'm not sure I could offer a different choice I would have preferred - so the criticism definitely isn't constructive in that sense. It does seem, though, that the world is missing a sane cross-platform network system. If there had even been some fuse-based system that used a more robust protocol I'd probably prefer that, although if they can more or less guarantee that the NFS service won't go down (easily) then I suppose most of my qualms would be put aside.

Re: Amazon Elastic File System

#22

Post by IgorPartola » Thu, Apr 09, 2015, 6:15 PM UTC

fi788 wrote: post #12

willcodeforfoo wrote: post #9

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.

S3 also seems to provide only eventual consistency.

Re: Amazon Elastic File System

#23

Post by jdubs » Thu, Apr 09, 2015, 6:18 PM UTC

shogun21 wrote: post #20

What's the advantage of this over S3?

EFS which appears to be similar to NFS is built into the kernel. Read, write, stat and etc do not need to be wrapped into http calls.

Re: Amazon Elastic File System

#24

Post by ceejayoz » Thu, Apr 09, 2015, 6:19 PM UTC

joemccall86 wrote: post #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?

I don't think anyone can really recommend EFS for anything yet until it's in the wild for testing. I'd probably still store static files like that on S3 - with EFS you'd still need a server to handle the requests.

Re: Amazon Elastic File System

#25

Post by skuhn » Thu, Apr 09, 2015, 6:19 PM UTC

joemccall86 wrote: post #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?

One thing to consider is that EFS is priced at 10x the cost of the most expensive tier of S3 storage ($0.30/Gbyte vs $0.03/Gbyte).

If they are just static assets, you would do better to put them in an S3 bucket, set appropriate Cache-Control headers and serve them via Cloudfront. This reduces your outbound bandwidth cost to the Internet versus EC2/S3, and yields better performance.

Re: Amazon Elastic File System

#26

Post by IgorPartola » Thu, Apr 09, 2015, 6:19 PM UTC

shogun21 wrote: post #20

What's the advantage of this over S3?

This is a filesystem. You mount it directly inside your EC2 boxes and work with it as if it's local (or really NFS-mounted). It's going to be a couple of orders of magnitude faster, but not directly web-connected, so you can't use it to serve content directly as if it was a CDN.

I can see this being useful for a few cases. For one, I can immediately use it for one of the projects I have where I have multiple worker servers and one of them needs to periodically process a few GB's of data, yet I don't want to give that much storage to every sever, and I don't want to make any one server special.

Another use case: you don't know how big your data will grow, yet you want to access it in a random fashion. S3 isn't great for this, but NFS is, and unlimited mounted storage is nice.

Edit: Third use case is logs. You can collect all the logs from all of your servers in one place and access them from any server.

Re: Amazon Elastic File System

#27

Post by ceejayoz » Thu, Apr 09, 2015, 6:20 PM UTC

IgorPartola wrote: post #22

fi788 wrote: post #12

Earlier quoted context omitted.

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.

S3 also seems to provide only eventual consistency.

http://aws.amazon.com/s3/faqs/

> Q: What data consistency model does Amazon S3 employ?

> Amazon S3 buckets in the US Standard region provide eventual consistency. Amazon S3 buckets in all other regions provide read-after-write consistency for PUTS of new objects and eventual consistency for overwrite PUTS and DELETES.

Re: Amazon Elastic File System

#28

Post by ekimekim » Thu, Apr 09, 2015, 6:22 PM UTC

joemccall86 wrote: post #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?

While there's alot of unknowns at this point, my money would be to stick with S3. Serving static files quickly is a large part of what it is designed to do. From what I'm reading here, EFS seems more geared towards shared volumes where it being a filesystem is a critical part of the interface. If you can get away with not needing a posix filesystem layer over your datastore, you should.

Re: Amazon Elastic File System

#29

Post by bmurphy1976 » Thu, Apr 09, 2015, 6:23 PM UTC

fi788 wrote: post #12

willcodeforfoo wrote: post #9

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.

As always, it depends on your use case. Just because it can be slow doesn't mean it's not a viable (and in some cases superior) option.

We use it to store petabytes of large video files and our system is structured such that no folder ever has more than a couple files in it (>20 is rare). With properly tuned caching this works fantastically well for our use case and I would take the simpler code and reduced points of failure over NFS nonsense any day.

That of course doesn't mean s3fs is the solution to every problem, it simply means it's good to have options and don't write something off because it "might be slow."

Know your data, know your use case, and know your tools. You can make smart decisions on your own rather than driven by anecdotal comments on HN.

Re: Amazon Elastic File System

#30

Post by SlalomStallone » Thu, Apr 09, 2015, 6:23 PM UTC

shogun21 wrote: post #20

What's the advantage of this over S3?

One nice thing would be hosting wordpress on multiple EC2 servers. All local copies of your wordpress directory would be kept in sync automatically with no other configuration.