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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
