Thanks Vijay, good to know. On 9 January 2017 at 09:59, Vijay Bellur <vbellur@xxxxxxxxxx> wrote: > > > 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 > -- Lindsay _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
