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
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Emmanuel Dreyfus m...@netbsd.org
Cc: Raghavendra Gowdappa rgowd...@redhat.com, Gluster Devel
gluster-devel@gluster.org
Sent: Wednesday, November 26, 2014 2:05:58 PM
Subject: Re: Wrong behavior on fsync of
On 11/25/2014 07:38 AM, Raghavendra Gowdappa wrote:
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Raghavendra Gowdappa rgowd...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org, Emmanuel Dreyfus
m...@netbsd.org
Sent: Tuesday, November 25, 2014 12:49:03 AM
On Tue, Nov 25, 2014 at 09:35:25AM +0100, Xavier Hernandez wrote:
Anyway it seems that there's a difference between linux and NetBSD because
this test only fails on NetBSD. Is it possible that linux's fuse
implementation delays the fsync request until all pending writes have been
answered ?
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Raghavendra Gowdappa rgowd...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org, Emmanuel Dreyfus
m...@netbsd.org
Sent: Tuesday, November 25, 2014 2:05:25 PM
Subject: Re: Wrong behavior on fsync of md-cache
On 11/25/2014 12:59 PM, Raghavendra Gowdappa wrote:
- Original Message -
From: Xavier Hernandez xhernan...@datalab.es
To: Raghavendra Gowdappa rgowd...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org, Emmanuel Dreyfus
m...@netbsd.org
Sent: Tuesday, November 25, 2014 2:05:25 PM
Xavier Hernandez xhernan...@datalab.es wrote:
An alternative would be to temporarily remove or change this test to
avoid the problem.
That would help on that test, but I suspect the same problem is
responsible for other spurious failures.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
Hi,
I have an issue in ec caused by what seems an incorrect behavior in
md-cache, at least in NetBSD (on linux this doesn't seem to happen).
The problem happens when multiple writes are sent in parallel and one of
them fails with an error. After the error, an fsync is issued, before
all
