Is it possible that volume mount returns before fuse_init() is executed
? if that's true, then the core is generated because just after mounting
the volume, statedumps are requested to determine when all ec childs are
up. The code in fuse's dump assumes that fuse_init() has already been
called
On 14/01/16 14:28, Jiffin Tony Thottan wrote:
Hi,
The core generated when encryption xlator is enabled
[2016-01-14 08:13:15.740835] E
[crypt.c:4298:master_set_master_vol_key] 0-test1-crypt: FATAL: missing
master key
[2016-01-14 08:13:15.740859] E [MSGID: 101019]
[xlator.c:429:xlator_init]
While doing rsync over millions of files from ordinary partition to
GlusterFS volume, just after approx. first 2 million rsync hang happens,
and the following info appears in dmesg:
===
[17075038.924481] INFO: task rsync:10310 blocked for more than 120
seconds.
[17075038.931948] "echo 0 >
Here is similar issue described on serverfault.com:
https://serverfault.com/questions/716410/rsync-crashes-machine-while-performing-sync-on-glusterfs-mounted-share
I've checked GlusterFS logs with no luck — as if nothing happened.
P.S. GlusterFS v3.7.6.
15.01.2016 09:40, Oleksandr Natalenko
On 01/14/2016 04:11 AM, Jiffin Tony Thottan wrote:
On 14/01/16 14:28, Jiffin Tony Thottan wrote:
Hi,
The core generated when encryption xlator is enabled
[2016-01-14 08:13:15.740835] E
[crypt.c:4298:master_set_master_vol_key] 0-test1-crypt: FATAL: missing
master key
[2016-01-14
