On Sun, Jan 8, 2017 at 5:29 PM, Lindsay Mathieson <lindsay.mathieson@xxxxxxxxx> wrote:
On 8/01/2017 10:38 AM, Lindsay Mathieson wrote:
Option: performance.flush-behind
Default Value: on
Description: If this option is set ON, instructs write-behind translator to perform flush in background, by returning success (or any errors, if any of previous writes were failed) to application even before flush FOP is sent to backend filesystem.
Does this mean that essentially fsync is disabled by default?
Also:
performance.write-behind : on
performance.strict-o-direct : off
It would appear that by default, fsync and O_DIRECT are off, and write-behind is on
Note that flush-behind does not alter the behavior of fsync() operations. fsync() in gluster by default is synchronous and returns only when all necessary fsync() operation(s) are complete in the brick(s). flush-behind being on would mean that a sequence of:
open() + write() + close() does not guarantee written data to be on disk.
However the following sequence guarantees that (with flush-behind being enabled or disabled) written data will be on disk:
open() + write() + fsync() + close().
As long as applications perform fsync() or open with O_SYNC, data that is written will be guaranteed to be on disk.
strict-o-direct is set to off by default to avoid confusions that have been around with O_DIRECT and documented in the NOTES section of man 2 open. write-behind is enabled by default and it honors O_SYNC/fsync() for syncing previously acknowledged write(s) to disk.
Regards,
Vijay
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
