vbellur at redhat.com
Sun Jan 8 23:59:28 UTC 2017
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?
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users