On Sun, Jan 8, 2017 at 5:29 PM, Lindsay Mathieson < [email protected]> 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 [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
