Comment by delta_p_delta_x | Hacker News Reader

Comment by delta_p_delta_x | Hacker News Reader

Parent Full thread

delta_p_delta_x

I don't quite see how web development is relevant here; I think you've missed the point. Just because it's 'object storage' doesn't mean developers are reaching for React, HTML, CSS, JavaScript, etc. Object storage is a means to put huge volumes of data elsewhere besides your own hard disk/solid state drives, or a NAS running in the basement/attic; that's all. They are a means to access that data at extremely large scale, and can work with native or web apps.

More importantly, object storage need not even exist in the cloud at all; there exist solutions to set up S3 and S3-compatible storage on-premises.

There are plenty of examples of native programs leveraging object storage, whether in the cloud, or on-premises. Consider the latest release of Microsoft Flight Simulator, which streams high-quality assets (city/building 3D models, terrain, textures, weather data, real-time NPC air traffic, etc) in real-time as the user flies over the virtual Earth[1]. The competition has distinctly worse graphical fidelity, primarily because of storage concerns.

Scientific data—especially astrophysics and telescope data—tends to be hosted on blob/object storage (albeit not necessarily on S3) because of the immense data volume involved. These include including Hubble, the Sloan Digital Sky Survey, the Transiting Exoplanet Satellite Survey (TESS), and the Kepler and K2 exoplanet missions.

[1]: https://www.techradar.com/news/microsoft-flight-simulator-20...

Disclaimer: I am an employee at cunoFS.

> There are plenty of examples of native programs leveraging object storage, whether in the cloud, or on-premises. Consider the latest release of Microsoft Flight Simulator, which streams high-quality assets (city/building 3D models, terrain, textures, weather data, real-time NPC air traffic, etc) in real-time as the user flies over the virtual Earth[1]. The competition has distinctly worse graphical fidelity, primarily because of storage concerns

Well that's cool, but why on earth would I expect to use a POSIX API for that, and conversely, why would I expect to use the API that presumably is used for that (decidely non-POSIX-y in most ways) when I want to interact with my own kernel and associated hardware? The tasks are fundamentally different.

"I want object storage APIs for local storage" <= completely reasonable

"I want object storate APIs to be like POSIX or vice versa" <= considerably less reasonable

Why? Because all typical, existing applications written for POSIX systems use the POSIX API (usually indirectly) to interact with the filesystem and perform IO. Being able to use that vast ecosystem of existing applications seamlessly with object storage is such a common requirement that a good dozen different object storage-to-POSIX abstraction layers exist (many of them on top of FUSE).

Even if you build your scalable production environment from scratch with native object storage support (which is rare!), it’s eminently useful to be able to use coreutils to interact with said object storage for devops: nothing beats e.g. running grep on a list of log “files” in an S3 bucket in terms of convenience.

Have you tried running Samba on top of cunoFS ? I'd be interested in performance data on that. For SMB3 access it might be better to add a Samba VFS vfs_cunoFS interface directly. You won't need to open source your client code, just the wrapper.

Hi sorry I missed this. Yes, you can run Samba for SMB, and Ganesha for NFSv4. Feel free to email us if you think there's a better way though.

Yes, I think there's a better way (which would make Samba faster on your system :-). Can you ping me at jra@samba.org and I'll explain !

Reply on news.ycombinator.com