131–140 of 169 posts
Interesting: Google flags, protocol buffers, and Google C++ style.
If you look at Baidu's infrastructure, it's almost like a parallel universe where the names are identical or almost identical to Google's: BFE, GTC, GSLB. And BFS does look a lot like GFS2 aka Colossus.
What I really want to know: "Once your code has passed the code-review and merged, it will be run on thousands of servers" And the Chinese text below says tens of thousands of servers, which is it? :-)
Considering Baidu's scale, it would be tens of thousands. There are several other discrepancies in the doc between the Chinese version and the English one. Some technical proofreading is needed.
For instance, Hindi has special names for 100000 (lakh), 10M (crore/karod) etc. so a similar translation to Hindi would use those even if it meant introducing a factor of 10 in the literal interpretation.
Looking through the code it supports fuse, but the documentation in ENG is sparse. It also looks to underpin Tera: the Baidu distributed DB. I think a low read/write latency dfs suitable for real time applications would be a game changer. I'm hoping they up the documentation from here and engage the English speaking community.
There is another distributed file system that support full POSIX semantics with well tuned FUSE client, called MooseFS [1].
My ex-employer used that in production for about 8 years, the biggest cluster has more than 2PB.
Disclosure: I'm a MooseFS fan and contributor :)
Earlier quoted context omitted.
Last time I checked English was the 3rd most spoken language on the planet. - Chinese - Spanish - English You mean in tech?
That's ordering by native speakers. If you count non-natives, English has far more speakers than Spanish (but far less than Mandarin).
Earlier quoted context omitted.
No, it's replicated read-write, but according to wikipedia, file locks are only machine-wide, so write collisions are easy to create.
Are you sure? From that same wikipedia: "AFS volumes can be replicated to read-only cloned copies."
Earlier quoted context omitted.
During non-GC periods, probably true. But having a realtime filesystem service that is prone to stop-the-world GC pauses is a showstopper for many applications. Also, a C++ implementation is likelier to use far less memory than a Java implementation, assuming the skills of both programmers are roughly equal.
The underlying local filesystem on each node is not truly realtime, so a "realtime distributed file system" is already quite a stretch. Also JVM is perfectly fine with pause times below a few tens of ms worst-case (when using properly tuned G1, CMS GC), which is lower than worst-case latency induced by network + I/O. As for using less memory - you don't allocate buffers for file data on the JVM heap. You allocate the…
Earlier quoted context omitted.
Do you mean hackery of this sort: http://blog.xebia.com/persistence-with-docker-containers-tea... Or do you know of clean, container only (no plugins or special external tools) solution ?
Oh, sorry, didn't realize we were playing the "move the goalposts" game. If you were to google for "gluster" and "containers" you'd get everything from slick marketing stuff to a presentation at the recent Gluster developer summit in Berlin. I have no idea if any of those would meet your next set of standards but, frankly, meh.