[Gluster-users] performance.flush-behind

[Lindsay Mathieson]

Thanks Vijay, good to know.

On 9 January 2017 at 09:59, Vijay Bellur <vbellur at redhat.com> wrote:
>
>
> 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
>



-- 
Lindsay