Live data from Hacker News

Garage: Open-Source Distributed Object Storage

garagehq.deuxfleurs.fr

51–60 of 147 posts

Re: Garage: Open-Source Distributed Object Storage

#52
post #50
post #31

Earlier quoted context omitted.

Are you claiming that SeaweedFS requires twice as much RAM as the sum of the sizes of the stored objects?

Correct. I experimented by varying the data volume, it was linearly correlated by x2 of data volume.

Create a reproducible issue in their github. The developer is very responsive.

Re: Garage: Open-Source Distributed Object Storage

#53
post #37

What I'm really missing in this space is something like this for content addressed blob storage. I feel like a lot of complexity and performance overhead could be reduced if you only store immutable blobs under their hash (e.g Blake3). Combined with a soft delete this would make all operations idempotent, blobs trivially cacheable, and all state a CRDT/monotonically mergeable/coordination free. There is stuff like IP…

you might be interested in https://github.com/perkeep/perkeep

Re: Garage: Open-Source Distributed Object Storage

#54

We moved over to garage after running minio in production with about ~2PB after about 2 years of headache. Minio does not deal with small files very well, rightfully so, since they don't keep a separate index of the files other than straight on disk. While ssd's can mask this issue to some extent, spinning rust, not so much. And speaking of replication, this just works... Minio's approach even with synchronous mode t…

quick question for advice - we have been evaluating minio for a in-house deployed storage for ML data. this is financial data which we have to comply on a crap ton of regulations.

so we wanted lots of compliance features - like access logs, access approvals, short lived (time bound) accesses, etc etc.

how would you compare garage vs minio on that front ?

Re: Garage: Open-Source Distributed Object Storage

#56

I don’t understand why everyone wants to replicate AWS APIs for things that are not AWS. S3 is a horrible interface with a terrible lack of features. It’s just file storage without any of the benefits of a file syste - no metadata, no directory structures, no ability to search, sort, or filter. Combine that with high latency network file access and an overly verbose API. You literally have a bucket for storing files,…

You wouldn't want your "interactive" user filesystem on S3, no, but as the storage backend for a server application it makes sense. In those cases you very often are just storing everything in a single flat folder with all the associated metadata in your application's DB instead

By reducing the API surface (to essentially just GET, PUT, DELETE), it increases the flexibility of the backend. It's almost trivial to do a union mount with object storage, where half the files go to one server and half go to another (based on a hash of the name). This can and is done with POSIX filesystems too, but it requires more work to fully satisfy the semantics. One of the biggest complications is having to support file modification and mmap. With S3 you can instead only modify a file by fully replacing it with PUT. Which again might be unacceptable for a desktop OS filesystem, but many server applications already satisfy this constraint by default

Re: Garage: Open-Source Distributed Object Storage

#57
post #37

What I'm really missing in this space is something like this for content addressed blob storage. I feel like a lot of complexity and performance overhead could be reduced if you only store immutable blobs under their hash (e.g Blake3). Combined with a soft delete this would make all operations idempotent, blobs trivially cacheable, and all state a CRDT/monotonically mergeable/coordination free. There is stuff like IP…

you might be interested in https://github.com/perkeep/perkeep

Or some even older prior art (which I recall a Perkeep dev citing as an influence in a conference talk)

http://doc.cat-v.org/plan_9/4th_edition/papers/venti/

https://en.wikipedia.org/wiki/Venti_(software)

Re: Garage: Open-Source Distributed Object Storage

#58
post #30

Last time I looked at Garage it only supported paired storage replication, such that if I had a 10GB disk in location A and a 1TB disk is location 2 and 3, it would only support "RAID1-esq" mirroring, so my storage would be limited to 10GB

That's a deliberate design decision.

Re: Garage: Open-Source Distributed Object Storage

#60
post #37

What I'm really missing in this space is something like this for content addressed blob storage. I feel like a lot of complexity and performance overhead could be reduced if you only store immutable blobs under their hash (e.g Blake3). Combined with a soft delete this would make all operations idempotent, blobs trivially cacheable, and all state a CRDT/monotonically mergeable/coordination free. There is stuff like IP…

you might be interested in https://github.com/perkeep/perkeep

Perkeep has (at least until last I checked it) the very interesting property of being completely impossible for me to make heads or tails of while also looking extremely interesting and useful.

So in the hope of triggering someone to give me the missing link (maybe even a hyperlink) for me to understand it, here is a the situation:

I'm a SW dev that also have done a lot of sysadmin work. Yes, I have managed to install it. And that is about it. There seems to be so many features there but I really really don't understand how I am supposed to use the product or the documentation for that matter.

I could start an import of Twitter or something else an it kind of shows up. Same with anything else: photos etc.

It clearly does something but it was impossible to understand what I am supposed to do next, both from the ui and also from the docs.

Post reply on HN