Re: Wrong behavior on fsync of md-cache ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux