4 ms·

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 d

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'?

notacoward 12y ago
If the back end is eventually consistent, how can you claim POSIX compliance on the front end? User writes and fsyncs, BFS node goes down, somebody tries to read. What will they get? Who the heck knows? The only in-memory copy is gone, and the back end you've chosen doesn't guarantee that you'll get the most recently written data on the next read. It's perfectly OK if you decide on a different consistency model, but then you can't say you're POSIX compliant (actually you can't anyway for legal reasons but that's another topic).
- shafiee01 12y ago
  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.
  - notacoward 12y ago
    > In POSIX if your buffer is not flushed there is no guarantee that you will get the latest version neither. That's not true. If it's not flushed there's no guarantee that it will be durable (i.e. on stable storage, will survive a crash of the entire system). However, there is a guarantee that it will be consistent. http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html http://pubs.opengroup.org/onlinepubs/009695399/functions/wri... > After a write() to a regular file has successfully returned: > Any successful read() from each byte position in the file that was modified by that write shall return the data specified by the write() Even more specifically, and relevantly to the current point... > If a read() of file data can be proven (by any means) to occur after a write() of the data, it must reflect that write(), even if the calls are made by different processes. Many POSIX requirements related to what the database folks would call ACID are hard to meet in a distributed file system, but they are nonetheless requirements. This particular requirement implies that if a node fails but the system as a whole remains up, then the last write must be immediately available. It could be met, for example, by doing your own synchronous in-memory replication. However, if you rely on pinging the data through a backing store that only provides eventual consistency, then the requirement is not met.

notacoward 12y ago

If the back end is eventually consistent, how can you claim POSIX compliance on the front end? User writes and fsyncs, BFS node goes down, somebody tries to read. What will they get? Who the heck knows? The only in-memory copy is gone, and the back end you've chosen doesn't guarantee that you'll get the most recently written data on the next read. It's perfectly OK if you decide on a different consistency model, but then you can't say you're POSIX compliant (actually you can't anyway for legal reasons but that's another topic).

shafiee01 12y ago
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.
- notacoward 12y ago
  > In POSIX if your buffer is not flushed there is no guarantee that you will get the latest version neither. That's not true. If it's not flushed there's no guarantee that it will be durable (i.e. on stable storage, will survive a crash of the entire system). However, there is a guarantee that it will be consistent. http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html http://pubs.opengroup.org/onlinepubs/009695399/functions/wri... > After a write() to a regular file has successfully returned: > Any successful read() from each byte position in the file that was modified by that write shall return the data specified by the write() Even more specifically, and relevantly to the current point... > If a read() of file data can be proven (by any means) to occur after a write() of the data, it must reflect that write(), even if the calls are made by different processes. Many POSIX requirements related to what the database folks would call ACID are hard to meet in a distributed file system, but they are nonetheless requirements. This particular requirement implies that if a node fails but the system as a whole remains up, then the last write must be immediately available. It could be met, for example, by doing your own synchronous in-memory replication. However, if you rely on pinging the data through a backing store that only provides eventual consistency, then the requirement is not met.