Google Acquires Elastifile • Hacker News Board

Re: Google Acquires Elastifile

#11

Post by dogismycopilot » Wed, Jul 10, 2019, 1:12 AM UTC

sciurus wrote: post #8

p_l wrote: post #7

Earlier quoted context omitted.

There's already GCP Filestore.

Filestore is basically a single google-managed instance running NFS. It's much less sophisticated and resilient than EFS, but also can be much faster since it doesn't have the overhead of a distributed system. Don't try running something that touches lots of files like mercurial on EFS, trust me... The article says Elastifile (which I know nothing about) will become part of filestore.

Filestore is also really expensive for what is basically just NFS.

Re: Google Acquires Elastifile

#12

Post by spydum » Wed, Jul 10, 2019, 1:13 AM UTC

choppaface wrote: post #9

It will be interesting to see how well this scales. I have seen AWS EFS fall over under heavy read load (lots of reads for the same TB-scale data). A lot of poor souls using Horovod with no data team use EFS to “distribute” data in data-parallel SGD.

EFS generally only falls down when you hit your IOPs limit for the measurement period -have seen this soooo many times. Buy more storage/IOPS, and monitor that puppy.

Re: Google Acquires Elastifile

#13

Post by ethbro » Wed, Jul 10, 2019, 1:42 AM UTC

dogismycopilot wrote: post #11

sciurus wrote: post #8

Earlier quoted context omitted.

Filestore is basically a single google-managed instance running NFS. It's much less sophisticated and resilient than EFS, but also can be much faster since it doesn't have the overhead of a distributed system. Don't try running something that touches lots of files like mercurial on EFS, trust me... The article says Elastifile (which I know nothing about) will become part of filestore.

Filestore is also really expensive for what is basically just NFS.

Managed services are generally for enterprise, where you're fully costing out support + security mitigation.

Eliminating team coordination tips the balance.

Re: Google Acquires Elastifile

#14

Post by geerlingguy » Wed, Jul 10, 2019, 1:53 AM UTC

ethbro wrote: post #13

dogismycopilot wrote: post #11

Earlier quoted context omitted.

Filestore is also really expensive for what is basically just NFS.

Managed services are generally for enterprise, where you're fully costing out support + security mitigation. Eliminating team coordination tips the balance.

EFS is... surprisingly cheap, as long as you don’t need heavy sustained IO for more than a few hours at a time. Great for a simple file store and some big data purposes.

Re: Google Acquires Elastifile

#15

Post by strin » Wed, Jul 10, 2019, 2:29 AM UTC

Looks like Elastifile allows users to "mount" cloud buckets to their servers as NFS. This allows them to run old desktop workflows without the need to migrate these workflows to the cloud.

The upside is that Google Cloud is getting serious about the enterprise because most of them still use desktop applications.

The question is how long this will last since the future is the cloud.

Re: Google Acquires Elastifile

#16

Post by objectivefs » Wed, Jul 10, 2019, 2:46 AM UTC

choppaface wrote: post #9

It will be interesting to see how well this scales. I have seen AWS EFS fall over under heavy read load (lots of reads for the same TB-scale data). A lot of poor souls using Horovod with no data team use EFS to “distribute” data in data-parallel SGD.

For TB-scale heavy read loads ObjectiveFS[0] is an alternative to EFS that don't have EFS's IO/bandwidth limits. It is often used for distributing data for machine learning and large scale simulations on EC2 and GCE.

[0]: https://objectivefs.com

Re: Google Acquires Elastifile

#17

Post by truth_seeker » Wed, Jul 10, 2019, 3:19 AM UTC

I would be interested to see how it compares with AWS EFS under a variety of load.

AWS EFS implements NFS 4.1 which support has support for massive parallel IO.

http://www.pnfs.com/

Re: Google Acquires Elastifile

#18

Post by hobofan » Wed, Jul 10, 2019, 8:07 AM UTC

spydum wrote: post #12

choppaface wrote: post #9

It will be interesting to see how well this scales. I have seen AWS EFS fall over under heavy read load (lots of reads for the same TB-scale data). A lot of poor souls using Horovod with no data team use EFS to “distribute” data in data-parallel SGD.

EFS generally only falls down when you hit your IOPs limit for the measurement period -have seen this soooo many times. Buy more storage/IOPS, and monitor that puppy.

IOPs is one of the main pitfalls of cloud platforms and I'm baffled that neither GCP nor AWS make it easier to detect that you are hitting a limit there.

I've had multiple gigs where I was tasked with solving performance pitfalls, and most of the time it was as simple as upping the IOPS. In one case even though the problem was resolved in the end, the client migrated away from the cloud again because of that bad experience.