[Gluster-users] performance.flush-behind

[Vijay Bellur]

On Sun, Jan 8, 2017 at 5:29 PM, Lindsay Mathieson <
lindsay.mathieson at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20170108/a0a363b7/attachment.html>