[Gluster-devel] Wrong behavior on fsync of md-cache ?

[Xavier Hernandez]

On 11/25/2014 06:45 PM, Xavier Hernandez wrote:
> On 11/25/2014 02:25 PM, Emmanuel Dreyfus wrote:
>> On Tue, Nov 25, 2014 at 01:42:21PM +0100, Xavier Hernandez wrote:
>>> It seems to fail only in NetBSD. I'm not sure what priority it has.
>>> Emmanuel
>>> is trying to create a regression test for new patches that checks all
>>> tests
>>> in tests/basic, and tests/basic/ec/quota.t hits this issue.
>>
>> FWIW, I just tried to change NetBSD FUSE to queue fsync after write, but
>> that does not help, I still crash in dht_writev_cbk()
>>
>
> Not sure what could be the problem. I added a sleep between 'dd' and
> 'rm' to let all pending writes to finish before removing the file and it
> seemed to pass the test reliably.

On second though, I think your change on fuse haven't solved the problem 
because fuse really sees all answers to the writes it has sent.

If I understand correctly how write-behind works, when it receives a 
write, it queues it to be processed later, but immediately returns an 
answer to the upper layers. This is why write-behind improves performance.

This means that it won't be possible to solve the problem in the fuse 
layer because it doesn't have enough information about the real state of 
all caches.

Raghavendra, if that's true, fsync will need to be propagated always, 
even in case of error so that other xlators (even the remote brick 
filesystem) will have a chance to flush its caches, if any.

Not sure if this could be important/interesting, but I think (not really 
sure) that posix says that only answered writes must be flushed on 
fsync. If a recent write has been received but not yet answered when 
fsync is received, it's not mandatory to flush it.

Xavi