----- Original Message ----- > From: "Xavier Hernandez" <xhernandez@xxxxxxxxxx> > To: "Emmanuel Dreyfus" <manu@xxxxxxxxxx> > Cc: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > 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 > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
