Live data from Hacker News

Amazon Elastic File System

aws.amazon.com

161–170 of 217 posts

Re: Amazon Elastic File System

#161
post #36

Does anyone else cringe when someone suggestions using NFS in production? I can't be the only one that has been woken up at 2am because of an NFS outage.

That sounds like an issue with the implementation, not the protocol. There are countless large environments I know of running NFS in production on NetApp without any issues at all.

Re: Amazon Elastic File System

#162

Earlier quoted context omitted.

Maybe you didn't notice, but they just invented the Watch. Imagine...if you could put a whole entire clock...on your wrist. Almost everybody has a wrist!

Says the guy who will own one within a year. Or the Android knock off.

PSSST: Android watches were a thing long before Apple pre-announced theirs.

Re: Amazon Elastic File System

#163
post #90
post #75

Earlier quoted context omitted.

Thanks for the time-saving description. Osx also has a built-in NFS client.

Until Amazon starts offering EC2 OS X instances, I'm not sure that's as relevant.

I assume Amazon can't offer EC2 OS X instances until Apple allows OS X to be virtualized

Re: Amazon Elastic File System

#164

Earlier quoted context omitted.

Maybe you didn't notice, but they just invented the Watch. Imagine...if you could put a whole entire clock...on your wrist. Almost everybody has a wrist!

Says the guy who will own one within a year. Or the Android knock off.

The Android knockoff that was released a year beforehand.

Re: Amazon Elastic File System

#165
NFS? I just simply don't see the place for this product. The world moved towards the use of smart data formats on platforms like S3 and HDFS. Where would be a NFS service better? It is kind of hard to see for me to use a distributed filesystem over a distributed datastore. Wondering about the outage scenarios with that. Historically speaking, the drivers that deal with this in the linux kernel are not the best in terms of locking.

http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_03.h...

This is a step back from the right direction to me.

Re: Amazon Elastic File System

#166

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 workload…

We'll be providing a lot more details later.

Jeff, does EFS have some kind of "backing store" to S3? EFS -> S3 -> Glacier sounds really interesting.

Re: Amazon Elastic File System

#167
post #59
post #46

Earlier quoted context omitted.

For the record, there has never been anything stopping you from spinning up an NFS EC2 that all of your other EC2s can use.

Except that your one EC2 instance is a single point of failure, from instance through host through availability zone, and that providing reliable, multi-node NFS is hard (even with GlusterFS). And you have to resize your block devices to store more stuff. And... And... :-)

Well, this is a problem with a lot of ephemeral services hand-spun on AWS. There are also ways of mitigating it on your instances, but those are clunky, too.

Which is why new services like these are always preferable.

Re: Amazon Elastic File System

#168
post #102
post #42

Earlier quoted context omitted.

As has been mentioned, EBS can only be mounted to one instance at a time. If you could mount it to multiple it would effectively be the same thing, but then you have all sorts of write-locking issues. As the rest of the comments also allude, a lot of the cloud-entrenched world has abandoned NFS, or at least in AWS circles. I'm not one of these people. Rather than relying solely on puppet->all instances to handle mult…

Would it be a good idea to store Mysql db on EFS to be shared among load-balanced instances?

As simonw points out, it produces a real problem with regard to MySQL and the way it handles its data source(s) in general, but more importantly, it's wholly unnecessary.

The right way to do that (in AWS world) would be RDS accessible to all instances in the security group. This yields locking control to the application level and not the file system. For obvious reasons this makes a lot of sense.

There are of course non-ACID / NoSQL solutions for which this might be an acceptable practice, but in general I'd say it's fraught with peril.

Re: Amazon Elastic File System

#169

EFS is a great addition to AWS. We have SAN as a service via EBS, now we get NFS as a service. Great. The question (for me) now becomes "where do we go from here?" Infinite NFS is great, but what I've always wanted is infinite EBS that is fully integrated from file system to SAN. In other words, something that behaves like a local file system (without the gotchas of NFS like a lack of delete on close), but I don't ha…

[deleted]

Re: Amazon Elastic File System

#170

EFS is a great addition to AWS. We have SAN as a service via EBS, now we get NFS as a service. Great. The question (for me) now becomes "where do we go from here?" Infinite NFS is great, but what I've always wanted is infinite EBS that is fully integrated from file system to SAN. In other words, something that behaves like a local file system (without the gotchas of NFS like a lack of delete on close), but I don't ha…

something that behaves like a local file system (without the gotchas of NFS like a lack of delete on close), but I don't have to snapshot and create new volumes and issue file system expansion commands to grow a volume. I want seamless and automatic growth.

Wouldn't EBS w/ thin provisioning get you most of this? Just create a massive volume, and you get billed for the space actually used. (and the volume size could also function as a limit on your bill.)

Post reply on HN