3 ms·

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 f

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

> 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.