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

[Raghavendra Gowdappa]

----- Original Message -----
> From: "Xavier Hernandez" <xhernandez at datalab.es>
> To: "Emmanuel Dreyfus" <manu at netbsd.org>
> Cc: "Raghavendra Gowdappa" <rgowdapp at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Wednesday, November 26, 2014 2:05:58 PM
> Subject: Re: Wrong behavior on fsync of md-cache ?
> 
> 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.

Xavi, yes you are right. I'll take that into consideration.

> 
> 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
>