Xavi,
I enabled TRACE logging. The log grew up to 120GB and could not
make much out of it. Then I started logging GFID in the code where we were
seeing errors.
[2017-01-13 17:02:01.761349] I [dict.c:3065:dict_dump_to_log]
0-glusterfsProd-disperse-0: dict=0x7fa6706bc690
Hi Ram,
On 12/01/17 22:14, Ankireddypalle Reddy wrote:
Xavi,
I changed the logging to log the individual bytes. Consider the
following from ws-glus.log file where /ws/glus is the mount point.
[2017-01-12 20:47:59.368102] I [MSGID: 109063]
[dht-layout.c:718:dht_layout_normalize]
Hi Xavier,
I went through the source code. Some questions remain.
1. If two clients try to write to same file, it should succeed, even if
they overlap. (Locks should ensure it happens in sequence, in the bricks).
from the source code
lock->flock.l_type = F_WRLCK;
Hi,
I try write FOP test on case of volume of gusterfs is full, the detail process
and some investigation is as the below:
--
1) use dd to write full with
Hi,
On 13/01/17 10:58, jayakrishnan mm wrote:
Hi Xavier,
I went through the source code. Some questions remain.
1. If two clients try to write to same file, it should succeed, even if
they overlap. (Locks should ensure it happens in sequence, in the bricks).
from the source code
