Live data from Hacker News

HopsFS: 100x Times Faster Than AWS S3

logicalclocks.com

131–139 of 139 posts

Re: HopsFS: 100x Times Faster Than AWS S3

#131
post #81

Disclosure: I work on Google Cloud. Cool work! I love seeing people pushing distributed storage. IIUC though, you make a similar choice as Avere and others. You're treating the object store as a distributed block store [1]: > In HopsFS-S3, we added configuration parameters to allow users to provide their Amazon S3 bucket to be used as the block data store. Similar to HopsFS, HopsFSS3 stores the small files, 128 KB, H…

> interop is too valuable

Good point, JuiceFS already provides this "transparent mode", which is called compatible mode.

Re: HopsFS: 100x Times Faster Than AWS S3

#132

Earlier quoted context omitted.

> S3 requests to US buckets might be served by delayed replicas in other countries if the request comes from outside the US What? That makes no sense. Do you have a source for that? I thought the explicit choice of region when creating a bucket limits where data is located. Why would the give you geo-replication for free? Also: "Amazon S3 creates buckets in a Region you specify. To optimize latency, minimize costs, o…

They also say "A process writes a new object to Amazon S3 and immediately lists keys within its bucket. Until the change is fully propagated, the object might not appear in the list" which implies that you cannot read immediately after write.

No. It does not imply that. It only implies that it might not be included in a List Operation. That's all this sentence tells you.

Re: HopsFS: 100x Times Faster Than AWS S3

#133

I have VM for my data scientists already in GCP, my datasets live in Google Cloud Storage. Can I take advantage of HopsFS for a shared file system across my VMs. Google Filestore Is ridículous expensive and at least they give u 1TB. Multi writer only supports 2VMs

JuiceFS supports GCS and can be used in GCP, we have customers use it for data scientists. JuiceFS is free if you don't have data more than 1TB.

Discloser: Founder of JuiceFS here

Re: HopsFS: 100x Times Faster Than AWS S3

#134
post #81

Disclosure: I work on Google Cloud. Cool work! I love seeing people pushing distributed storage. IIUC though, you make a similar choice as Avere and others. You're treating the object store as a distributed block store [1]: > In HopsFS-S3, we added configuration parameters to allow users to provide their Amazon S3 bucket to be used as the block data store. Similar to HopsFS, HopsFSS3 stores the small files, 128 KB, H…

>It's somewhat unclear to me, but I think the combination of these statements means "S3 is always treated as a block store, but sometimes the File == Variably-Sized-Block == Object. Is that right? If the file is "small" (under a configure size, typically 128KB), it is stored in the metadata-layer, not on S3. Otherwise, if you just write the file once in one session (and it is under the 5TB object size limit in S3), t…

Your upcoming flexibility sounds awesome. I assume many people would just mark the entire bucket as “compatible” to support arbitrary renames/mv of directories, but being able to say “keep this directory in compat mode” for people who use a single mega bucket and split into teams / datasets at the top will be nice.

I’m sorry if you’ve tried to talk to us and we’ve been unhelpful. I’d be happy to put you in touch with some GCS people specifically — the Colossus folks are multiple layers below, while the AI folks are multiple layers above. They were probably mostly not sure what to say!

We worked quite openly and frankly with the Twitter folks on our GCS connector [1]. I’d be happy to help support doing the same with you. My contact info is in my profile.

(Though I’d definitely agree that we’ve also been surprisingly reticent to talk about Colossus, until recently the only public talk was some slides at FAST).

[1] https://cloud.google.com/blog/products/data-analytics/new-re...

Re: HopsFS: 100x Times Faster Than AWS S3

#135
post #83

Earlier quoted context omitted.

Disclosure: I work on Google Cloud. If Filestore (our managed NFS product) is too large for you, I'd suggest having gcsfuse on each box (or just use the GCS Connector for Hadoop). You won't get the kind of NFS-style locking semantics that a real distributed filesystem would support, but it sounds like you mostly need your data scientists to be able to read and write from buckets as if they're a local filesystem (and…

Thanks for replying, is there any performance numbers for gcsfuse. We use small files and large files. We write small files at high rate. (Jupyter Notebooks) and can read and write large files (models) I also started looking into the multi writer and wondering if there are new developments (nodes >2)

More than anything, gcsfuse and similar projects that don’t put a separate metadata / data cache in between, reflect GCS’s latency and throughput (with a bit of an extra burden for being done through fuse).

GCS has pretty high latency. So even if you write a single byte, expect it to be like 50+ms. This is slower than a spinning disk in an old computer. If you’re just updating a single person’s notebook, they’ll feel it a bit on save (but obviously each person and file is independent).

But you can also do about 1 Gbps per network stream (and putting several of those together, 32+ Gbps per VM) such that even a 1 MB file is also probably done in about that much time. I think for streaming writes (save model) gcsfuse may still do a local copy until some threshold before writing out.

I’d probably put your models directly on GCS though. That’s what we do in colab and with TensorFlow (sadly, it seems from a quick search that PyTorch doesn’t have this out of the box).

Filestore and multi-writer PD will naturally improve over time. But I’m guessing you need something “today”. Feel free to send me a note (contact in profile) if you want to share specifics.

Re: HopsFS: 100x Times Faster Than AWS S3

#136

Do you plan on having s Kubernetes storage provider? I like the idea of present a POSIX like mount to s container while paying per use for storage in S3

You can do this using s3backer, goofys etc to mount S3 as a host filesystem and then use the host path provisioner.

The hostPath provisioner has just RWO access mode, which means only single node. For RWX (read-write in multi-node), Goofys could be used via CSI though.

Re: HopsFS: 100x Times Faster Than AWS S3

#138

Earlier quoted context omitted.

Depending on your write throughput, versioning can be quite expensive. Also, we were already at a throughput where the s3 metadata nodes would sometimes go offline, so I'm not sure putting more work on them would have improved our overall situation.

Interesting, do you have more information on how you did monitors these S3 metadata nodes? Never heard of that. Why would an unversioned put be less costly than a versioned put? To me it should be pretty much the same. I would almost suspect unversioned puts are hacked around versioned ones. Out of curiosity what kind of workload did you perform? I have been moving terabytes of files (some very small 1kB files, some…

> Interesting, do you have more information on how you did monitors these S3 metadata nodes? Never heard of that.

Pretty simple, we started a bulk import, and then HTTPS requests to amazonaws.com started timing out... Later, support told us to spread out our requests to alleviate the load spike.

What we did was process roughly 50mio 1MB JPEG images from the full-res S3 bucket into an derived-data S3 bucket.

Re: HopsFS: 100x Times Faster Than AWS S3

#139

Earlier quoted context omitted.

A Unix file system is not only a map from paths to inodes to bytes. Unix file systems support a host of additional apis, some of which are hard to implement on top of something like s3 (eg atomically renaming a parent path). Even if you drop the Unix (posix) part, most practically used file systems have features that are hard to guarantee in a distributed setting, and in either case simply don't exist in S3.

The point in my post was to point out that storage implemented using keys and values is fundamental to all filesystems. To say that the very model that is fundamental to all filesystem is the thing that somehow precludes S3 from being considered a filesystem is kind of bizarre. Also Nowhere did I say or even imply that a key/value store is all a Unix file system is. Different filesystems have different features. Obje…

I understood the original poster as saying a system providing only key/value storage is not the same as a file system. I'd think that's something we can all agree on?
Post reply on HN