This is really useful; I have been recently working on a huge c++ project and I had the exact same problem you mentioned with large vectors. The way I handled this problem was to wrap vector in a class which provides locking mechanism for expanding operations so while the vector is growing nobody can access it.
I am excited to try Rust soon.
If you flush a file it will be in the backend; Therefore, even if a node goes down, another node will be responsible for that. There will be obviously a delay for the recovery. In POSIX if your buffer is not flushed there is no guarantee that you will get the latest version neither.
Yeah, maybe I should totally get rid of that "POSIX" compatible thing. I had that in mind because I expose my fs interface through fuse library and supposedly they cover POSIX.
I wish if I could :) but right now in our lab I don't have access to such equipments. Honestly, that was the plan because using 10/40G networks will significantly reduce the delay in remote operations as well as increasing the throughput in remote operations.
Yes, I plan to run experiments with different numbers of threads/files and many other factors. Right know I only have access to a cluster of 7 old machines. That's the best I can do and for the hadoop case I used all of the machines.
Sure thing I will provide all of the commands that I used. I just made this project public to get this type of comments. I have not written or explained anything yet. So there are A LOT to explain like the questions you raised. I will try to answer them here as well:
Here is a big sketch of the system: Nodes use fuse to provide a traditional file system view to applications. Zookeeper is used for consensus and it keeps track of what file (name) each node is holding. Swift (or any other persistent storage) is used as the backend. Nodes communicate through TCP or Zero_networking to each other for remote IO operations.
* When a file is flushed my consistency/durability guarantees are whatever the backend storage is. If swift, then it's swift's consistency/durability guarantees. While in memory (not flushed or closed) it's consistent because there is only one copy of file at the host node but not durable because if that node dies it's gone.
if a node fails there is a master (elected with zookeeper) which will assign the files that node was holding to other nodes (assuming that nodes has flushed it's files to the backend). Failure in zookeeper and swift are out of my project scope.
As soon as the system starts, it goes through a zookeeper master election and then master distributes files in the backends to the live nodes.
* right now it's just a silly algorithm (the most free node) however, it can/should be changed to a more advanced mechanism which probably considers load and many other factors as well.
I am very happy to answer your questions and I really enjoyed answering them. I am sure this is the type of question I will get in my defence session as well. And that's why I post this in the news. :)
Awesome, it will be great if other people can contribute in my project. There are many things left to do and a tons of space for improvement. Maybe we can discuss more through email.
1- This is just a preliminary evaluation. I just made the repository public 3 hours ago. I am planning so many experiments including the ones you mentioned.
2- As I said more benchmark including multiple files with iozone, postmark are coming. This is just to give viewer a sense.
P.S I am happy with my supervisor :) thanks for your recommendations though ;)
1-Well if you don't want to use a backend storage what else do you expect?
2-It will flush as soon as you call flush or close your file. It's not necessarily disk and can be any configured backend (right now only swift is supported; however, it's easy to develop other backends as well)
3-Replication is done in the backend storage. Once your data is flushed it's replicated to your desire in Swift, Amazon or whatever backend you are using. What do you mean 'nor works in aralllel'?