Thanks for your help with this, Anand, and sorry for sitting on it for a
while...
On 28/07/14 18:57, Anand Avati wrote:
Whether flush-behind is enabled or not, close() will guarantee all
previous write()s on that fd have been acknowledged by server.
Thanks Anand. So can you
On Mon, Jul 28, 2014 at 10:43 AM, Richard van der Hoff <
rich...@swiftserve.com> wrote:
> On 28/07/14 18:05, Anand Avati wrote:
>
>> Whether flush-behind is enabled or not, close() will guarantee all
>> previous write()s on that fd have been acknowledged by server.
>>
>
> Thanks Anand. So can you
On 28/07/14 18:05, Anand Avati wrote:
Whether flush-behind is enabled or not, close() will guarantee all
previous write()s on that fd have been acknowledged by server.
Thanks Anand. So can you explain why the 'wc' in my example doesn't see
all of the data written by the dd?
$ dd
Whether flush-behind is enabled or not, close() will guarantee all previous
write()s on that fd have been acknowledged by server. It is just the post
processing of close() itself which is performed in background when
flush-behind is enabled. The word "flush" here is probably confusing as it
is spec
Would anyone be able to help out with this question?
Thanks
Richard
On 11/07/14 00:08, Pranith Kumar Karampuri wrote:
CC write-behind Dev
On 07/10/2014 11:59 PM, Richard van der Hoff wrote:
Hi folks,
Just wondering if anyone could clear up a question about expected
behavior for the performa
CC write-behind Dev
On 07/10/2014 11:59 PM, Richard van der Hoff wrote:
Hi folks,
Just wondering if anyone could clear up a question about expected
behavior for the performance/writebehind translator.
I'm using Gluster 3.3, with a single volume which is distributed to
two bricks on a pair of
Hi folks,
Just wondering if anyone could clear up a question about expected
behavior for the performance/writebehind translator.
I'm using Gluster 3.3, with a single volume which is distributed to two
bricks on a pair of servers. I have performance.flush-behind=off; the
documentation [1] lea
