From bugzilla at redhat.com Fri Mar 1 05:30:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 05:30:06 +0000
Subject: [Bugs] [Bug 1682925] Gluster volumes never heal during oVirt
4.2->4.3 upgrade
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1682925
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |urgent
Version|4.3 |5
CC| |bugs at gluster.org
Component|Installation & Update |replicate
Assignee|sabose at redhat.com |bugs at gluster.org
Product|ovirt-node |GlusterFS
QA Contact|weiwang at redhat.com |
Summary|Gluster volumes never heal |Gluster volumes never heal
|during 4.2->4.3 upgrade |during oVirt 4.2->4.3
| |upgrade
Target Milestone|ovirt-4.3.2 |---
Flags|testing_ack? |
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 05:31:36 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 05:31:36 +0000
Subject: [Bugs] [Bug 1682925] Gluster volumes never heal during oVirt
4.2->4.3 upgrade
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1682925
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sabose at redhat.com
Blocks| |1677319
| |(Gluster_5_Affecting_oVirt_
| |4.3)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1677319
[Bug 1677319] [Tracker] Gluster 5 issues affecting oVirt 4.3
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 06:30:24 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 06:30:24 +0000
Subject: [Bugs] [Bug 1676546] Getting client connection error in gluster logs
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676546
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22289
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 06:30:25 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 06:30:25 +0000
Subject: [Bugs] [Bug 1676546] Getting client connection error in gluster logs
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676546
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22289 (Afr: Avoid logging of \"attempting to
connect\") posted (#1) for review on master by Rinku Kothiya
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 06:48:21 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 06:48:21 +0000
Subject: [Bugs] [Bug 1676546] Getting client connection error in gluster logs
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676546
Rinku changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rkothiya at redhat.com
Assignee|bugs at gluster.org |rkothiya at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 07:04:59 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 07:04:59 +0000
Subject: [Bugs] [Bug 1684385] New: [ovirt-gluster] Rolling gluster upgrade
from 3.12.5 to 5.3 led to shard on-disk xattrs disappearing
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
Bug ID: 1684385
Summary: [ovirt-gluster] Rolling gluster upgrade from 3.12.5 to
5.3 led to shard on-disk xattrs disappearing
Product: GlusterFS
Version: 5
Status: NEW
Component: core
Keywords: Triaged
Assignee: bugs at gluster.org
Reporter: kdhananj at redhat.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
When gluster bits were upgraded in a hyperconverged ovirt-gluster setup, one
node at a time in online mode from 3.12.5 to 5.3, the following log messages
were seen -
[2019-02-26 16:24:25.126963] E [shard.c:556:shard_modify_size_and_block_count]
(-->/usr/lib64/glusterfs/5.3/xlator/cluster/distribute.so(+0x82a45)
[0x7ff71d05ea45] -->/usr/lib64/glusterfs/5.3/xlator/features/shard.so(+0x5c77)
[0x7ff71cdb4c77] -->/usr/lib64/glusterfs/5.3/xlator/features/shard.so(+0x592e)
[0x7ff71cdb492e] ) 0-engine-shard: Failed to get
trusted.glusterfs.shard.file-size for 3ad3f0c6-a4e6-4b17-bd29-97c32ecc54d7
Version-Release number of selected component (if applicable):
How reproducible:
1/1
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
shard.file.size xattr should always be accessible.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 07:13:48 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 07:13:48 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
--- Comment #1 from Krutika Dhananjay ---
[root at tendrl25 glusterfs]# gluster v info engine
Volume Name: engine
Type: Replicate
Volume ID: bb26f648-2842-4182-940e-6c8ede02195f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: tendrl27.lab.eng.blr.redhat.com:/gluster_bricks/engine/engine
Brick2: tendrl26.lab.eng.blr.redhat.com:/gluster_bricks/engine/engine
Brick3: tendrl25.lab.eng.blr.redhat.com:/gluster_bricks/engine/engine
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
performance.quick-read: off
performance.read-ahead: off
performance.io-cache: off
performance.low-prio-threads: 32
network.remote-dio: off
cluster.eager-lock: enable
cluster.quorum-type: auto
cluster.server-quorum-type: server
cluster.data-self-heal-algorithm: full
cluster.locking-scheme: granular
cluster.shd-max-threads: 8
cluster.shd-wait-qlength: 10000
features.shard: on
user.cifs: off
storage.owner-uid: 36
storage.owner-gid: 36
network.ping-timeout: 30
performance.strict-o-direct: on
cluster.granular-entry-heal: enable
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 07:23:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 07:23:02 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
--- Comment #2 from Krutika Dhananjay ---
On further investigation, it was found that the shard xattrs were genuinely
missing on all 3 replicas -
[root at tendrl27 ~]# getfattr -d -m . -e hex
/gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
getfattr: Removing leading '/' from absolute path names
# file:
gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.engine-client-1=0x000000000000000000000000
trusted.afr.engine-client-2=0x000000000000000000000000
trusted.gfid=0x3ad3f0c6a4e64b17bd2997c32ecc54d7
trusted.gfid2path.5f2a4f417210b896=0x64373265323737612d353761642d343136322d613065332d6339346463316231366230322f696473
[root at localhost ~]# getfattr -d -m . -e hex
/gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
getfattr: Removing leading '/' from absolute path names
# file:
gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.engine-client-0=0x0000000e0000000000000000
trusted.afr.engine-client-2=0x000000000000000000000000
trusted.gfid=0x3ad3f0c6a4e64b17bd2997c32ecc54d7
trusted.gfid2path.5f2a4f417210b896=0x64373265323737612d353761642d343136322d613065332d6339346463316231366230322f696473
[root at tendrl25 ~]# getfattr -d -m . -e hex
/gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
getfattr: Removing leading '/' from absolute path names
# file:
gluster_bricks/engine/engine/36ea5b11-19fb-4755-b664-088f6e5c4df2/dom_md/ids
security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.engine-client-0=0x000000100000000000000000
trusted.afr.engine-client-1=0x000000000000000000000000
trusted.gfid=0x3ad3f0c6a4e64b17bd2997c32ecc54d7
trusted.gfid2path.5f2a4f417210b896=0x64373265323737612d353761642d343136322d613065332d6339346463316231366230322f696473
Also from the logs, it appears the file underwent metadata self-heal moments
before these errors started to appear-
[2019-02-26 13:35:37.253896] I [MSGID: 108026]
[afr-self-heal-metadata.c:52:__afr_selfheal_metadata_do] 0-engine-replicate-0:
performing metadata selfheal on 3ad3f0c6-a4e6-4b17-bd29-97c32ecc54d7
[2019-02-26 13:35:37.254734] W [MSGID: 101016] [glusterfs3.h:752:dict_to_xdr]
0-dict: key 'trusted.glusterfs.shard.file-size' is not sent on wire [Invalid
argument]
[2019-02-26 13:35:37.254749] W [MSGID: 101016] [glusterfs3.h:752:dict_to_xdr]
0-dict: key 'trusted.glusterfs.shard.block-size' is not sent on wire [Invalid
argument]
[2019-02-26 13:35:37.255777] I [MSGID: 108026]
[afr-self-heal-common.c:1729:afr_log_selfheal] 0-engine-replicate-0: Completed
metadata selfheal on 3ad3f0c6-a4e6-4b17-bd29-97c32ecc54d7. sources=[0] sinks=2
[2019-02-26 13:35:37.258032] I [MSGID: 108026]
[afr-self-heal-metadata.c:52:__afr_selfheal_metadata_do] 0-engine-replicate-0:
performing metadata selfheal on 3ad3f0c6-a4e6-4b17-bd29-97c32ecc54d7
[2019-02-26 13:35:37.258792] W [MSGID: 101016] [glusterfs3.h:752:dict_to_xdr]
0-dict: key 'trusted.glusterfs.shard.file-size' is not sent on wire [Invalid
argument]
[2019-02-26 13:35:37.258807] W [MSGID: 101016] [glusterfs3.h:752:dict_to_xdr]
0-dict: key 'trusted.glusterfs.shard.block-size' is not sent on wire [Invalid
argument]
[2019-02-26 13:35:37.259633] I [MSGID: 108026]
[afr-self-heal-common.c:1729:afr_log_selfheal] 0-engine-replicate-0: Completed
metadata selfheal on 3ad3f0c6-a4e6-4b17-bd29-97c32ecc54d7. sources=[0] sinks=2
Metadata heal as we know does three things - 1. bulk getxattr from source
brick; 2. removexattr on sink bricks 3. bulk setxattr on the sink bricks
But what's clear from these logs is the dict_to_xdr() messages at the time of
metadata heal, indicating that the shard xattrs were possibly not "sent on
wire" as part of step 3.
Turns out due to the newly introduced dict_to_xdr() code in 5.3 which is absent
in 3.12.5.
The bricks were upgraded to 5.3 in the order tendrl25 followed by tendrl26 with
tendrl27 still at 3.12.5 when this issue was hit -
Tendrl25:
[2019-02-26 12:47:53.595647] I [MSGID: 100030] [glusterfsd.c:2715:main]
0-/usr/sbin/glusterfsd: Started running /usr/sbin/glusterfsd version 5.3 (args:
/usr/sbin/glusterfsd -s tendrl25.lab.eng.blr.redhat.com --volfile-id
engine.tendrl25.lab.eng.blr.redhat.com.gluster_bricks-engine-engine -p
/var/run/gluster/vols/engine/tendrl25.lab.eng.blr.redhat.com-gluster_bricks-engine-engine.pid
-S /var/run/gluster/aae83600c9a783dd.socket --brick-name
/gluster_bricks/engine/engine -l
/var/log/glusterfs/bricks/gluster_bricks-engine-engine.log --xlator-option
*-posix.glusterd-uuid=9373b871-cfce-41ba-a815-0b330f6975c8 --process-name brick
--brick-port 49153 --xlator-option engine-server.listen-port=49153)
Tendrl26:
[2019-02-26 13:35:05.718052] I [MSGID: 100030] [glusterfsd.c:2715:main]
0-/usr/sbin/glusterfsd: Started running /usr/sbin/glusterfsd version 5.3 (args:
/usr/sbin/glusterfsd -s tendrl26.lab.eng.blr.redhat.com --volfile-id
engine.tendrl26.lab.eng.blr.redhat.com.gluster_bricks-engine-engine -p
/var/run/gluster/vols/engine/tendrl26.lab.eng.blr.redhat.com-gluster_bricks-engine-engine.pid
-S /var/run/gluster/8010384b5524b493.socket --brick-name
/gluster_bricks/engine/engine -l
/var/log/glusterfs/bricks/gluster_bricks-engine-engine.log --xlator-option
*-posix.glusterd-uuid=18fa886f-8d1a-427c-a5e6-9a4e9502ef7c --process-name brick
--brick-port 49153 --xlator-option engine-server.listen-port=49153)
Tendrl27:
[root at tendrl27 bricks]# rpm -qa | grep gluster
glusterfs-fuse-3.12.15-1.el7.x86_64
glusterfs-libs-3.12.15-1.el7.x86_64
glusterfs-3.12.15-1.el7.x86_64
glusterfs-server-3.12.15-1.el7.x86_64
glusterfs-client-xlators-3.12.15-1.el7.x86_64
glusterfs-api-3.12.15-1.el7.x86_64
glusterfs-events-3.12.15-1.el7.x86_64
libvirt-daemon-driver-storage-gluster-4.5.0-10.el7_6.4.x86_64
glusterfs-gnfs-3.12.15-1.el7.x86_64
glusterfs-geo-replication-3.12.15-1.el7.x86_64
glusterfs-cli-3.12.15-1.el7.x86_64
vdsm-gluster-4.20.46-1.el7.x86_64
python2-gluster-3.12.15-1.el7.x86_64
glusterfs-rdma-3.12.15-1.el7.x86_64
And as per the metadata heal logs, the source was brick0 (corresponding to
tendrl27) and sink was brick 2 (corresponding to tendrl 25).
This means step 1 of metadata heal did a getxattr on tendrl27 which was still
at 3.12.5 and got the dicts with a certain format which didn't have the "value"
type (because it's only introduced in 5.3).
And this same dict was used for setxattr in step 3 which silently fails to add
"trusted.glusterfs.shard.block-size" and "trusted.glusterfs.shard.file-size"
xattrs to the setxattr request because of the dict_to_xdr() conversion failure
in protocol/client but succeeds the overall operation. So afr thought the heal
succeeded although the xattr that needed heal was never sent over the wire.
This led to one or more files ending up with shard xattrs removed on-disk
failing every other operation on it pretty much.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 07:25:25 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 07:25:25 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |high
Blocks| |1677319
| |(Gluster_5_Affecting_oVirt_
| |4.3)
Severity|unspecified |high
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1677319
[Bug 1677319] [Tracker] Gluster 5 issues affecting oVirt 4.3
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 07:29:29 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 07:29:29 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
--- Comment #3 from Krutika Dhananjay ---
So the backward compatibility was broken with the introduction of the following
patch -
Patch that broke this compatibility -
https://review.gluster.org/c/glusterfs/+/19098
commit 303cc2b54797bc5371be742543ccb289010c92f2
Author: Amar Tumballi
Date: Fri Dec 22 13:12:42 2017 +0530
protocol: make on-wire-change of protocol using new XDR definition.
With this patchset, some major things are changed in XDR, mainly:
* Naming: Instead of gfs3/gfs4 settle for gfx_ for xdr structures
* add iattx as a separate structure, and add conversion methods
* the *_rsp structure is now changed, and is also reduced in number
(ie, no need for different strucutes if it is similar to other response).
* use proper XDR methods for sending dict on wire.
Also, with the change of xdr structure, there are changes needed
outside of xlator protocol layer to handle these properly. Mainly
because the abstraction was broken to support 0-copy RDMA with payload
for write and read FOP. This made transport layer know about the xdr
payload, hence with the change of xdr payload structure, transport layer
needed to know about the change.
Updates #384
Change-Id: I1448fbe9deab0a1b06cb8351f2f37488cefe461f
Signed-off-by: Amar Tumballi
Any operation in a heterogeneous cluster which reads xattrs on-disk and
subsequently writes it (like metadata heal for instance) will cause one or more
on-disk xattrs to disappear.
In fact logs suggest even dht on-disk layouts vanished -
[2019-02-26 13:35:30.253348] I [MSGID: 109092]
[dht-layout.c:744:dht_layout_dir_mismatch] 0-engine-dht:
/36ea5b11-19fb-4755-b664-088f6e5c4df2: Disk layout missing, gfid =
d0735acd-14ec-4ef9-8f5f-6a3c4ae12c08
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 08:00:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:00:34 +0000
Subject: [Bugs] [Bug 1684404] New: Multiple shd processes are running on
brick_mux environmet
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
Bug ID: 1684404
Summary: Multiple shd processes are running on brick_mux
environmet
Product: GlusterFS
Version: mainline
Hardware: x86_64
Status: NEW
Component: glusterd
Severity: high
Priority: high
Assignee: bugs at gluster.org
Reporter: mchangir at redhat.com
CC: bugs at gluster.org, moagrawa at redhat.com, pasik at iki.fi
Depends On: 1683880
Blocks: 1672818 (glusterfs-6.0)
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1683880 +++
Description of problem:
Multiple shd processes are running while created 100 volumes in brick_mux
environment
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1. Create a 1x3 volume
2. Enable brick_mux
3.Run below command
n1=
n2=
n3=
for i in {1..10};do
for h in {1..20};do
gluster v create vol-$i-$h rep 3
$n1:/home/dist/brick$h/vol-$i-$h $n2:/home/dist/brick$h/vol-$i-$h
$n3:/home/dist/brick$h/vol-$i-$h force
gluster v start vol-$i-$h
sleep 1
done
done
for k in $(gluster v list|grep -v heketi);do gluster v stop $k
--mode=script;sleep 2;gluster v delete $k --mode=script;sleep 2;done
Actual results:
Multiple shd processes are running and consuming system resources
Expected results:
Only one shd process should be run
Additional info:
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1683880
[Bug 1683880] Multiple shd processes are running on brick_mux environmet
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 08:00:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:00:34 +0000
Subject: [Bugs] [Bug 1683880] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683880
Milind Changire changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1684404
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
[Bug 1684404] Multiple shd processes are running on brick_mux environmet
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Fri Mar 1 08:00:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:00:34 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Milind Changire changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1684404
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
[Bug 1684404] Multiple shd processes are running on brick_mux environmet
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 08:01:07 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:01:07 +0000
Subject: [Bugs] [Bug 1684404] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
Mohit Agrawal changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |moagrawa at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 08:22:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:22:31 +0000
Subject: [Bugs] [Bug 1684404] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22290
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Fri Mar 1 08:22:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:22:32 +0000
Subject: [Bugs] [Bug 1684404] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22290 (glusterd: Multiple shd processes are
spawned on brick_mux environment) posted (#1) for review on master by MOHIT
AGRAWAL
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Fri Mar 1 08:23:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 08:23:03 +0000
Subject: [Bugs] [Bug 1683880] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683880
Mohit Agrawal changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Mohit Agrawal ---
Upstream patch is posted to resolve the same
https://review.gluster.org/#/c/glusterfs/+/22290/
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Fri Mar 1 11:34:42 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 11:34:42 +0000
Subject: [Bugs] [Bug 1684496] New: compiler errors building qemu against
glusterfs-6.0-0.1.rc0.fc30
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684496
Bug ID: 1684496
Summary: compiler errors building qemu against
glusterfs-6.0-0.1.rc0.fc30
Product: GlusterFS
Version: 6
Status: NEW
Component: libgfapi
Assignee: bugs at gluster.org
Reporter: kkeithle at redhat.com
QA Contact: bugs at gluster.org
CC: anoopcs at redhat.com, bugs at gluster.org,
crobinso at redhat.com, extras-qa at fedoraproject.org,
humble.devassy at gmail.com, jonathansteffan at gmail.com,
kkeithle at redhat.com, matthias at saou.eu,
ndevos at redhat.com, ramkrsna at gmail.com
Depends On: 1684298
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1684298 +++
qemu fails to rebuild in rawhide, seems like glusterfs related issues, using
6.0-0.1.rc0.fc31
https://koji.fedoraproject.org/koji/taskinfo?taskID=33109555
https://kojipkgs.fedoraproject.org//work/tasks/9555/33109555/build.log
A few example errors below. Any idea what's going on here?
BUILDSTDERR: /builddir/build/BUILD/qemu-3.1.0/block/gluster.c: In function
'qemu_gluster_co_pwrite_zeroes':
BUILDSTDERR: /builddir/build/BUILD/qemu-3.1.0/block/gluster.c:994:52: warning:
passing argument 4 of 'glfs_zerofill_async' from incompatible pointer type
[-Wincompatible-pointer-types]
BUILDSTDERR: 994 | ret = glfs_zerofill_async(s->fd, offset, size,
gluster_finish_aiocb, &acb);
BUILDSTDERR: |
^~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: | |
BUILDSTDERR: | void
(*)(struct glfs_fd *, ssize_t, void *) {aka void (*)(struct glfs_fd *, long
int, void *)}
BUILDSTDERR: In file included from
/builddir/build/BUILD/qemu-3.1.0/block/gluster.c:12:
BUILDSTDERR: /usr/include/glusterfs/api/glfs.h:993:73: note: expected
'glfs_io_cbk' {aka 'void (*)(struct glfs_fd *, long int, struct glfs_stat *,
struct glfs_stat *, void *)'} but argument is of type 'void (*)(struct glfs_fd
*, ssize_t, void *)' {aka 'void (*)(struct glfs_fd *, long int, void *)'}
BUILDSTDERR: 993 | glfs_zerofill_async(glfs_fd_t *fd, off_t length, off_t
len, glfs_io_cbk fn,
BUILDSTDERR: |
~~~~~~~~~~~~^~
BUILDSTDERR: /builddir/build/BUILD/qemu-3.1.0/block/gluster.c: In function
'qemu_gluster_do_truncate':
BUILDSTDERR: /builddir/build/BUILD/qemu-3.1.0/block/gluster.c:1035:13: error:
too few arguments to function 'glfs_ftruncate'
BUILDSTDERR: 1035 | if (glfs_ftruncate(fd, offset)) {
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684298
[Bug 1684298] compiler errors building qemu against glusterfs-6.0-0.1.rc0.fc30
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 11:44:40 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 11:44:40 +0000
Subject: [Bugs] [Bug 1684496] compiler errors building qemu against
glusterfs-6.0-0.1.rc0.fc30
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684496
Kaleb KEITHLEY changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |NOTABUG
Last Closed| |2019-03-01 11:44:40
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 11:48:22 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 11:48:22 +0000
Subject: [Bugs] [Bug 1684496] compiler errors building qemu against
glusterfs-6.0-0.1.rc0.fc30
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684496
Kaleb KEITHLEY changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1684500
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684500
[Bug 1684500] compiler errors building qemu against glusterfs-6.0-0.1.rc0.fc30
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 14:51:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 14:51:45 +0000
Subject: [Bugs] [Bug 1684569] New: Upgrade from 4.1 and 5 is broken
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
Bug ID: 1684569
Summary: Upgrade from 4.1 and 5 is broken
Product: GlusterFS
Version: 5
OS: Linux
Status: NEW
Component: core
Assignee: bugs at gluster.org
Reporter: kompastver at gmail.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Created attachment 1539843
--> https://bugzilla.redhat.com/attachment.cgi?id=1539843&action=edit
logs on srv1 after upgrading and starting glusterfs
Description of problem:
Online upgrade for replicated volumes cause upgraded node to be in "Peer
Rejected" state.
Version-Release number of selected component (if applicable):
>From 4.1.7 to 5.4
How reproducible:
Always
Steps to Reproduce:
1. setup replicated volume on v4.1
2. kill all gluster* processes on the first node
3. upgrade rpms up to v5.4
4. start gluster* processes on the first node
Actual results:
Peer is being rejected. And cluster operates without upgraded node.
`gluster peer status` shows:
State: Peer Rejected (Connected)
Expected results:
Online upgrade should works without downtime
Additional info:
Please see logs file in the attachment.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 14:52:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 14:52:34 +0000
Subject: [Bugs] [Bug 1684569] Upgrade from 4.1 and 5 is broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
--- Comment #1 from Znamensky Pavel ---
Created attachment 1539845
--> https://bugzilla.redhat.com/attachment.cgi?id=1539845&action=edit
logs on srv2 after upgrading srv1
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 18:20:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 18:20:03 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22291
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Fri Mar 1 18:20:04 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 01 Mar 2019 18:20:04 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #572 from Worker Ant ---
REVIEW: https://review.gluster.org/22291 (fd.c : remove redundant checks,
CALLOC -> MALLOC) posted (#1) for review on master by Yaniv Kaul
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:54:52 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:54:52 +0000
Subject: [Bugs] [Bug 1683900] Failed to dispatch handler
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683900
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-02 11:54:52
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22282 (socket: socket event handlers now
return void) merged (#2) on release-6 by Shyamsundar Ranganathan
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:54:53 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:54:53 +0000
Subject: [Bugs] [Bug 1667103] GlusterFS 5.4 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1667103
Bug 1667103 depends on bug 1683900, which changed state.
Bug 1683900 Summary: Failed to dispatch handler
https://bugzilla.redhat.com/show_bug.cgi?id=1683900
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:55:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:55:14 +0000
Subject: [Bugs] [Bug 1683716] glusterfind: revert shebangs to
#!/usr/bin/python3
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683716
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-02 11:55:14
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22275 (glusterfind: revert shebangs to
#!/usr/bin/python3) merged (#4) on release-6 by Shyamsundar Ranganathan
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:58:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:58:05 +0000
Subject: [Bugs] [Bug 1684777] New: gNFS crashed when processing "gluster v
profile [vol] info nfs"
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684777
Bug ID: 1684777
Summary: gNFS crashed when processing "gluster v profile [vol]
info nfs"
Product: GlusterFS
Version: 6
Status: NEW
Component: nfs
Keywords: Triaged
Assignee: bugs at gluster.org
Reporter: srangana at redhat.com
CC: bugs at gluster.org, jefferymymy at 163.com
Depends On: 1677559
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1677559 +++
Description of problem:
when processing "gluster v profile [vol] info nfs" after gnfs start, gnfs will
crash.
dump trace info:
/lib64/libglusterfs.so.0(_gf_msg_backtrace_nomem+0xc2)[0x7fcf5cb6a872]
/lib64/libglusterfs.so.0(gf_print_trace+0x324)[0x7fcf5cb743a4]
/lib64/libc.so.6(+0x35670)[0x7fcf5b1d5670]
/usr/sbin/glusterfs(glusterfs_handle_nfs_profile+0x114)[0x7fcf5d066474]
/lib64/libglusterfs.so.0(synctask_wrap+0x12)[0x7fcf5cba1502]
/lib64/libc.so.6(+0x47110)[0x7fcf5b1e7110]
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.create dht volume naming dht_vol,and start the vol
2.start volume profile
3.kill gnfs process
4.process cli "service glusterd restart;gluster volume profile dht_vol info
nfs"
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1677559
[Bug 1677559] gNFS crashed when processing "gluster v profile [vol] info nfs"
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:58:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:58:05 +0000
Subject: [Bugs] [Bug 1677559] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1677559
Shyamsundar changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1684777
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684777
[Bug 1684777] gNFS crashed when processing "gluster v profile [vol] info nfs"
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:59:30 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:59:30 +0000
Subject: [Bugs] [Bug 1677559] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1677559
--- Comment #4 from Worker Ant ---
REVISION POSTED: https://review.gluster.org/22235 (glusterfsd: Do not process
PROFILE_NFS_INFO if graph is not ready) posted (#2) for review on release-6 by
Shyamsundar Ranganathan
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:59:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:59:31 +0000
Subject: [Bugs] [Bug 1677559] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1677559
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID|Gluster.org Gerrit 22235 |
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:59:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:59:32 +0000
Subject: [Bugs] [Bug 1684777] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684777
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22235
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sat Mar 2 11:59:33 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 02 Mar 2019 11:59:33 +0000
Subject: [Bugs] [Bug 1684777] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684777
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22235 (glusterfsd: Do not process
PROFILE_NFS_INFO if graph is not ready) posted (#2) for review on release-6 by
Shyamsundar Ranganathan
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sun Mar 3 19:13:40 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 03 Mar 2019 19:13:40 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22292
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sun Mar 3 19:13:40 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 03 Mar 2019 19:13:40 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #573 from Worker Ant ---
REVIEW: https://review.gluster.org/22292 (inode.c/h: CALLOC->MALLOC) posted
(#1) for review on master by Yaniv Kaul
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sun Mar 3 19:35:04 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 03 Mar 2019 19:35:04 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22293
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Sun Mar 3 19:35:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 03 Mar 2019 19:35:05 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #574 from Worker Ant ---
REVIEW: https://review.gluster.org/22293 (stack.h: alignment of structures and
met_get0 -> mem_get) posted (#1) for review on master by Yaniv Kaul
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 02:29:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 02:29:46 +0000
Subject: [Bugs] [Bug 1683816] Memory leak when peer detach fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683816
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-04 02:29:46
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22280 (mgmt/glusterd: Fix a memory leak when
peer detach fails) merged (#1) on master by Vijay Bellur
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 02:30:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 02:30:27 +0000
Subject: [Bugs] [Bug 1684569] Upgrade from 4.1 and 5 is broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amukherj at redhat.com
Component|core |glusterd
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 02:30:47 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 02:30:47 +0000
Subject: [Bugs] [Bug 1684569] Upgrade from 4.1 and 5 is broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |srakonde at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 03:13:48 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 03:13:48 +0000
Subject: [Bugs] [Bug 1684969] New: New GFID file recreated in a replica set
after a GFID mismatch resolution
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684969
Bug ID: 1684969
Summary: New GFID file recreated in a replica set after a GFID
mismatch resolution
Product: GlusterFS
Version: 6
Status: NEW
Component: distribute
Severity: high
Priority: high
Assignee: bugs at gluster.org
Reporter: nbalacha at redhat.com
CC: bugs at gluster.org
Depends On: 1661258, 1670259
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1670259 +++
If the gfid is not set for a directory on one brick, a lookup on that directory
will cause a different GFID to be set on it, leading to a GFID mismatch.
--- Additional comment from Nithya Balachandran on 2019-01-29 04:56:49 UTC ---
Steps to reproduce the problem:
1. Create a 3 brick distribute volume
2. Fuse mount the volume and create some directories.
cd /mnt/fuse1
mkdir gfid-mismatch
mkdir gfid-mismatch/dir-1
3. delete the gfid and .glusterfs handle from the hashed brick
[root at rhgs313-6 brick1]# setfattr -x trusted.gfid vol1-1/gfid-mismatch/dir-1
[root at rhgs313-6 brick1]# unlink
vol1-1/.glusterfs/8e/6c/8e6c686c-93e9-4bd7-ac5e-98bbf852a62b
[root at rhgs313-6 brick1]#
[root at rhgs313-6 brick1]#
[root at rhgs313-6 brick1]#
[root at rhgs313-6 brick1]# getx vol1-*/gfid-mismatch/dir-1
# file: vol1-1/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.glusterfs.dht=0x00000000000000000000000055555554
trusted.glusterfs.dht.mds=0x00000000
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
# file: vol1-2/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.gfid=0x8e6c686c93e94bd7ac5e98bbf852a62b
trusted.glusterfs.dht=0x000000000000000055555555aaaaaaa9
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
# file: vol1-3/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.gfid=0x8e6c686c93e94bd7ac5e98bbf852a62b
trusted.glusterfs.dht=0x0000000000000000aaaaaaaaffffffff
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
4. Unmount and remount the fuse mount and list the contents of gfid-mismatch
[root at rhgs313-6 ~]# umount -f /mnt/fuse1; mount -t glusterfs -s
192.168.122.6:/vol1 /mnt/fuse1
[root at rhgs313-6 ~]# cd /mnt/fuse1
[root at rhgs313-6 fuse1]# cd gfid-mismatch/
[root at rhgs313-6 gfid-mismatch]# l
total 20K
drwxr-xr-x. 2 root root 4.0K Jan 29 09:20 dir-1
5. Check the gfid for dir-1 on the backend bricks.
[root at rhgs313-6 brick1]# getx vol1-*/gfid-mismatch/dir-1
# file: vol1-1/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.gfid=0x0c3a4860f93f416cb5261c3b2b06f52d < ---- GFID is DIFFERENT!!
trusted.glusterfs.dht=0x00000000000000000000000055555554
trusted.glusterfs.dht.mds=0x00000000
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
# file: vol1-2/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.gfid=0x8e6c686c93e94bd7ac5e98bbf852a62b
trusted.glusterfs.dht=0x000000000000000055555555aaaaaaa9
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
# file: vol1-3/gfid-mismatch/dir-1
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.gfid=0x8e6c686c93e94bd7ac5e98bbf852a62b
trusted.glusterfs.dht=0x0000000000000000aaaaaaaaffffffff
trusted.glusterfs.mdata=0x010000000000000000000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3000000005c4fcd7500000000017863f3
The GFID on brick vol1-1 is set to
trusted.gfid=0x0c3a4860f93f416cb5261c3b2b06f52d
The original GFID was:
trusted.gfid=0x8e6c686c93e94bd7ac5e98bbf852a62b
--- Additional comment from Nithya Balachandran on 2019-01-29 04:58:11 UTC ---
Upstream patch:
https://review.gluster.org/#/c/glusterfs/+/22112/
--- Additional comment from Worker Ant on 2019-02-02 03:10:15 UTC ---
REVIEW: https://review.gluster.org/22112 (cluster/dht: Do not use gfid-req in
fresh lookup) merged (#7) on master by Amar Tumballi
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1670259
[Bug 1670259] New GFID file recreated in a replica set after a GFID mismatch
resolution
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 03:13:48 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 03:13:48 +0000
Subject: [Bugs] [Bug 1670259] New GFID file recreated in a replica set after
a GFID mismatch resolution
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670259
Nithya Balachandran changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1684969
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684969
[Bug 1684969] New GFID file recreated in a replica set after a GFID mismatch
resolution
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 03:15:11 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 03:15:11 +0000
Subject: [Bugs] [Bug 1684969] New GFID file recreated in a replica set after
a GFID mismatch resolution
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684969
Nithya Balachandran changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 03:18:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 03:18:27 +0000
Subject: [Bugs] [Bug 1684969] New GFID file recreated in a replica set after
a GFID mismatch resolution
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684969
Nithya Balachandran changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Resolution|--- |CURRENTRELEASE
Last Closed| |2019-03-04 03:18:27
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 03:38:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 03:38:38 +0000
Subject: [Bugs] [Bug 1684777] gNFS crashed when processing "gluster v
profile [vol] info nfs"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684777
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-04 03:38:38
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22235 (glusterfsd: Do not process
PROFILE_NFS_INFO if graph is not ready) merged (#3) on release-6 by Amar
Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 04:21:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 04:21:41 +0000
Subject: [Bugs] [Bug 1672656] glustereventsd: crash,
ABRT report for package glusterfs has reached 100 occurrences
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672656
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |Triaged
Priority|unspecified |medium
Status|NEW |ASSIGNED
CC| |atumball at redhat.com
Severity|unspecified |high
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 04:57:01 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 04:57:01 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
--- Comment #52 from abhays ---
(In reply to Raghavendra Bhat from comment #50)
> Hi,
>
> Thanks for the logs. From the logs saw that the following things are
> happening.
>
> 1) The scrubbing is started
>
> 2) Scrubber always decides whether a file is corrupted or not by comparing
> the stored on-disk signature (gets by getxattr) with its own calculated
> signature of the file.
>
> 3) Here, while getting the on-disk signature, getxattr is failing with
> ENOMEM (i.e. Cannot allocate memory) because of the endianness.
>
> 4) Further testcases in the test fail because, they expect the bad-file
> extended attribute to be present which scrubber could not set because of the
> above error (i.e. had it been able to successfully get the signature of the
> file via getxattr, it would have been able to compare the signature with its
> own calculated signature and set the bad-file extended attribute to indicate
> the file is corrupted).
>
>
> Looking at the code to come up with a fix to address this.
Thanks for the reply @Raghavendra. We are also looking into the same.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 05:23:28 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 05:23:28 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
--- Comment #53 from abhays ---
(In reply to Nithya Balachandran from comment #51)
> >
> >
> > I don't think so. I would recommend that you debug the tests on your systems
> > and post patches which will work on both.
>
> Please note what I am referring to is for you to look at the .t files and
> modify file names or remove hardcoding as required.
Yes @Nithya, We understood that you want us to continue debugging the tests and
provide patches if fix is found.
While doing the same, we were able to fix the ./tests/bugs/nfs/bug-847622.t
with the following patch:-
diff --git a/tests/bugs/nfs/bug-847622.t b/tests/bugs/nfs/bug-847622.t
index 3b836745a..f21884972 100755
--- a/tests/bugs/nfs/bug-847622.t
+++ b/tests/bugs/nfs/bug-847622.t
@@ -28,7 +32,7 @@ cd $N0
# simple getfacl setfacl commands
TEST touch testfile
-TEST setfacl -m u:14:r testfile
+TEST setfacl -m u:14:r $B0/brick0/testfile
TEST getfacl testfile
Please check, if the above patch can be merged.
However, the test cases are still failing and only pass if x86 hash values are
provided(Refer to comment#8):-
./tests/bugs/glusterfs/bug-902610.t
./tests/bugs/posix/bug-1619720.t
We have tried modifying filenames in these test cases, but nothing worked.
We think that the test cases might pass if the behavior of the source code for
hash value calculation is changed to support s390x architecture as well.
Could you please look into the same?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 05:35:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 05:35:44 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
Nithya Balachandran changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(abhaysingh1722 at ya
| |hoo.in)
--- Comment #54 from Nithya Balachandran ---
>
> However, the test cases are still failing and only pass if x86 hash values
> are provided(Refer to comment#8):-
> ./tests/bugs/glusterfs/bug-902610.t
> ./tests/bugs/posix/bug-1619720.t
Please provide more information on what changes you tried.
>
> We have tried modifying filenames in these test cases, but nothing worked.
> We think that the test cases might pass if the behavior of the source code
> for hash value calculation is changed to support s390x architecture as well.
> Could you please look into the same?
This seem extremely unlikely at this point. Like I said, the code will work
fine as long as the setup is not mixed-endian. As the test cases are the only
things that fail and that is because they use hard coded values, such a huge
change in the source code is not the first step.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 05:56:36 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 05:56:36 +0000
Subject: [Bugs] [Bug 1676429] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676429
Susant Kumar Palai changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|bugs at gluster.org |spalai at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 06:21:00 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 06:21:00 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1672818 (glusterfs-6.0)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 06:21:00 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 06:21:00 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1684385
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
[Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from 3.12.5 to 5.3 led to
shard on-disk xattrs disappearing
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 06:21:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 06:21:34 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Sahina Bose changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1672318
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672318
[Bug 1672318] "failed to fetch volume file" when trying to activate host in DC
with glusterfs 3.12 domains
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 07:19:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 07:19:31 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
abhays changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(abhaysingh1722 at ya |
|hoo.in) |
--- Comment #55 from abhays ---
(In reply to Nithya Balachandran from comment #54)
> >
> > However, the test cases are still failing and only pass if x86 hash values
> > are provided(Refer to comment#8):-
> > ./tests/bugs/glusterfs/bug-902610.t
> > ./tests/bugs/posix/bug-1619720.t
>
> Please provide more information on what changes you tried.
For tests/bugs/glusterfs/bug-902610.t:-
In the test case, after the kill_brick function is run, the mkdir $M0/dir1
doesn't work and hence the get_layout function test fails. So,as a workaround
we tried not killing the brick and then checked the functionality of the test
case, after which the dir1 did get created in all the 4 bricks, however, the
test failed with the following output:-
=========================
TEST 9 (line 59): ls -l /mnt/glusterfs/0
ok 9, LINENUM:59
RESULT 9: 0
getfattr: Removing leading '/' from absolute path names
/d/backends/patchy3/dir1 /d/backends/patchy0/dir1 /d/backends/patchy2/dir1
/d/backends/patchy1/dir1
layout1 from 00000000 to 00000000
layout2 from 00000000 to 55555554
target for layout2 = 55555555
=========================
TEST 10 (line 72): 0 echo 1
not ok 10 Got "1" instead of "0", LINENUM:72
RESULT 10: 1
Failed 1/10 subtests
=========================
But, the below patch works for the test case(only on Big Endian):-
diff --git a/tests/bugs/glusterfs/bug-902610.t
b/tests/bugs/glusterfs/bug-902610.t
index b45e92b8a..8a8eaf7a3 100755
--- a/tests/bugs/glusterfs/bug-902610.t
+++ b/tests/bugs/glusterfs/bug-902610.t
@@ -2,6 +2,7 @@
. $(dirname $0)/../../include.rc
. $(dirname $0)/../../volume.rc
+. $(dirname $0)/../../dht.rc
cleanup;
@@ -11,11 +12,11 @@ function get_layout()
layout1=`getfattr -n trusted.glusterfs.dht -e hex $1 2>&1|grep dht
|cut -d = -f2`
layout1_s=$(echo $layout1 | cut -c 19-26)
layout1_e=$(echo $layout1 | cut -c 27-34)
- #echo "layout1 from $layout1_s to $layout1_e" > /dev/tty
+ echo "layout1 from $layout1_s to $layout1_e" > /dev/tty
layout2=`getfattr -n trusted.glusterfs.dht -e hex $2 2>&1|grep dht
|cut -d = -f2`
layout2_s=$(echo $layout2 | cut -c 19-26)
layout2_e=$(echo $layout2 | cut -c 27-34)
- #echo "layout2 from $layout2_s to $layout2_e" > /dev/tty
+ echo "layout2 from $layout2_s to $layout2_e" > /dev/tty
if [ x"$layout2_s" = x"00000000" ]; then
# Reverse so we only have the real logic in one place.
@@ -29,7 +30,7 @@ function get_layout()
# Figure out where the join point is.
target=$( $PYTHON -c "print '%08x' % (0x$layout1_e + 1)")
- #echo "target for layout2 = $target" > /dev/tty
+ echo "target for layout2 = $target" > /dev/tty
# The second layout should cover everything that the first doesn't.
if [ x"$layout2_s" = x"$target" -a x"$layout2_e" = x"ffffffff" ]; then
@@ -41,26 +42,30 @@ function get_layout()
BRICK_COUNT=4
-TEST glusterd
+TEST glusterd --log-level DEBUG
TEST pidof glusterd
TEST $CLI volume create $V0 $H0:$B0/${V0}0 $H0:$B0/${V0}1 $H0:$B0/${V0}2
$H0:$B0/${V0}3
## set subvols-per-dir option
TEST $CLI volume set $V0 subvols-per-directory 3
TEST $CLI volume start $V0
+TEST $CLI volume set $V0 client-log-level DEBUG
+TEST $CLI volume set $V0 brick-log-level DEBUG
+
## Mount FUSE
TEST glusterfs -s $H0 --volfile-id $V0 $M0 --entry-timeout=0
--attribute-timeout=0;
TEST ls -l $M0
+#brick_loc=$(get_backend_paths $M0)
## kill 2 bricks to bring down available subvol < spread count
-kill_brick $V0 $H0 $B0/${V0}2
-kill_brick $V0 $H0 $B0/${V0}3
+kill_brick $V0 $H0 $B0/${V0}0
+kill_brick $V0 $H0 $B0/${V0}1
mkdir $M0/dir1 2>/dev/null
-get_layout $B0/${V0}0/dir1 $B0/${V0}1/dir1
+get_layout $B0/${V0}2/dir1 $B0/${V0}3/dir1
EXPECT "0" echo $?
cleanup;
>From above patch, the below output is seen:-
=========================
TEST 9 (line 59): ls -l /mnt/glusterfs/0
ok 9, LINENUM:59
RESULT 9: 0
Socket=/var/run/gluster/e90af2b6fbd74dbe.socket
Brick=/d/backends/patchy0
connected
disconnected
OK
Socket=/var/run/gluster/d7212ecddcb22a08.socket
Brick=/d/backends/patchy1
connected
disconnected
OK
layout1 from 00000000 to 7ffffffe
layout2 from 7fffffff to ffffffff
target for layout2 = 7fffffff
=========================
TEST 10 (line 72): 0 echo 0
ok 10, LINENUM:72
RESULT 10: 0
ok
All tests successful.
Files=1, Tests=10, 13 wallclock secs ( 0.03 usr 0.01 sys + 2.05 cusr 0.34
csys = 2.43 CPU)
Result: PASS
=========================
Therefore, can these changes be added in the test case with a condition for
s390x separately?
Also, We have a few queries on the tests behaviour.
When a directory or a file gets created, according to me, it should be placed
in the brick depending on its hash range and value of the file/directory.
However, in the above test, as you can see, if we don't kill the bricks{2,3},
the directory gets created in all the bricks{0,1,2,3}.So, does it not consider
hash values and range at this point or is it something to do with mounting
FUSE?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 07:51:58 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 07:51:58 +0000
Subject: [Bugs] [Bug 1685023] New: FD processes for larger files are not
closed soon after FOP finished
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685023
Bug ID: 1685023
Summary: FD processes for larger files are not closed soon
after FOP finished
Product: GlusterFS
Version: mainline
Status: NEW
Component: bitrot
Assignee: bugs at gluster.org
Reporter: david.spisla at iternity.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Docs Contact: bugs at gluster.org
Description of problem:
I did some observations concerning the bitrot daemon. It seems to be that the
bitrot signer is signing files depending on file size. I copied files with
different sizes into a volume and I was wonderung because the files get their
signature not the same time (I keep the expiry time default with 120). Here are
some examples:
300 KB file ~2-3 m
70 MB file ~ 40 m
115 MB file ~ 1 Sh
800 MB file ~ 4,5 h
There was already a bug from 2016:
https://bugzilla.redhat.com/show_bug.cgi?id=1378466
I also figured out this discussion:
https://lists.gluster.org/pipermail/gluster-users/2016-September/028354.html
Kotresh mentioned there that the problem is because for some files, fd process
are still up in the brick process list. Bitrot signer can only sign a file if
the fd is closed. And according to my observations it seems to be that as
bigger a file is as longer the fd is still up. I could verify this with a
500MiB file and some smaller files. After a specific time only the fd for the
500MiB was up and the file still had no signature, for the smaller files there
were no fds and they already had a signature.
Version-Release number of selected component (if applicable):
Gluster v5.3
Actual behaviour:
The fd processes are still up for a specific time (maybe depend on file
size???) after FOP finished and bitd can't sign the file
Expected behaviour:
The fd processes should be closed soon after FOP finished so that bitd can sign
the file
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the Docs Contact for the bug.
From bugzilla at redhat.com Mon Mar 4 08:15:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 08:15:27 +0000
Subject: [Bugs] [Bug 1685027] New: Error handling in
/usr/sbin/gluster-eventsapi produces IndexError: tuple index out of range
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685027
Bug ID: 1685027
Summary: Error handling in /usr/sbin/gluster-eventsapi produces
IndexError: tuple index out of range
Product: GlusterFS
Version: mainline
Status: NEW
Component: eventsapi
Keywords: EasyFix, ZStream
Assignee: bugs at gluster.org
Reporter: avishwan at redhat.com
CC: dahorak at redhat.com, rhs-bugs at redhat.com,
sanandpa at redhat.com, sankarshan at redhat.com,
sheggodu at redhat.com
Depends On: 1600459
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1600459 +++
Description of problem:
During testing of RHGS WA, I've found following traceback raised from
/usr/sbin/gluster-eventsapi script:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
File "/usr/sbin/gluster-eventsapi", line 666, in
runcli()
File "/usr/lib/python2.7/site-packages/gluster/cliutils/cliutils.py", line
224, in runcli
cls.run(args)
File "/usr/sbin/gluster-eventsapi", line 329, in run
sync_to_peers(args)
File "/usr/sbin/gluster-eventsapi", line 177, in sync_to_peers
"{1}".format(e[0], e[2]),
IndexError: tuple index out of range
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The prospective real issue is hidden beside this traceback.
Version-Release number of selected component (if applicable):
glusterfs-events-3.12.2-13.el7rhgs.x86_64
How reproducible:
100% if you will be able to cause the raise of GlusterCmdException
Steps to Reproduce:
I'm not sure, how to reproduce it from scratch, as my knowledge related
to gluster-eventsapi is very limited, but the problem is quite well
visible from the source code:
Open /usr/sbin/gluster-eventsapi script and look for function sync_to_peers
around line 171:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
171 def sync_to_peers(args):
172 if os.path.exists(WEBHOOKS_FILE):
173 try:
174 sync_file_to_peers(WEBHOOKS_FILE_TO_SYNC)
175 except GlusterCmdException as e:
176 handle_output_error("Failed to sync Webhooks file: [Error:
{0}]"
177 "{1}".format(e[0], e[2]),
178 errcode=ERROR_WEBHOOK_SYNC_FAILED,
179 json_output=args.json)
180
181 if os.path.exists(CUSTOM_CONFIG_FILE):
182 try:
183 sync_file_to_peers(CUSTOM_CONFIG_FILE_TO_SYNC)
184 except GlusterCmdException as e:
185 handle_output_error("Failed to sync Config file: [Error: {0}]"
186 "{1}".format(e[0], e[2]),
187 errcode=ERROR_CONFIG_SYNC_FAILED,
188 json_output=args.json)
189
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Important lines are 177 and 186:
"{1}".format(e[0], e[2]),
The problem is, that the GlusterCmdException is raised this way[1]:
raise GlusterCmdException((rc, out, err))
So all three parameters rc, out and err are supplied as one parameter (of type
tuple).
Actual results:
Any problem leading to raise of GlusterCmdException is hidden beside
above mentioned exception.
Expected results:
There shouldn't be any such traceback.
Additional info:
[1] file /usr/lib/python2.7/site-packages/gluster/cliutils/cliutils.py
--- Additional comment from Daniel Hor?k on 2018-07-13 08:23:29 UTC ---
Possible Reproduction scenario might be, to remove (rename)
/var/lib/glusterd/events/ directory on one Gluster Storage Node and try to add
webhook from another storage node:
On Gluster node 5:
# mv /var/lib/glusterd/events/ /var/lib/glusterd/events_BACKUP
On Gluster node 1:
# gluster-eventsapi webhook-add http://0.0.0.0:8697/test
Traceback (most recent call last):
File "/usr/sbin/gluster-eventsapi", line 666, in
runcli()
File "/usr/lib/python2.7/site-packages/gluster/cliutils/cliutils.py", line
224, in runcli
cls.run(args)
File "/usr/sbin/gluster-eventsapi", line 329, in run
sync_to_peers(args)
File "/usr/sbin/gluster-eventsapi", line 177, in sync_to_peers
"{1}".format(e[0], e[2]),
IndexError: tuple index out of range
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1600459
[Bug 1600459] Error handling in /usr/sbin/gluster-eventsapi produces
IndexError: tuple index out of range
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 08:15:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 08:15:41 +0000
Subject: [Bugs] [Bug 1685027] Error handling in /usr/sbin/gluster-eventsapi
produces IndexError: tuple index out of range
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685027
Aravinda VK changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|bugs at gluster.org |avishwan at redhat.com
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 09:11:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 09:11:44 +0000
Subject: [Bugs] [Bug 1685051] New: New Project create request
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
Bug ID: 1685051
Summary: New Project create request
Product: GlusterFS
Version: mainline
Status: NEW
Component: project-infrastructure
Assignee: bugs at gluster.org
Reporter: avishwan at redhat.com
CC: bugs at gluster.org, gluster-infra at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
Please create a new project under Github Gluster organization
Name: devblog
Description: Gluster Developer Blog posts
Admins:
@aravindavk Aravinda VK
@amarts Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 09:13:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 09:13:44 +0000
Subject: [Bugs] [Bug 1596787] glusterfs rpc-clnt.c: error returned while
attempting to connect to host: (null), port 0
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1596787
--- Comment #8 from Worker Ant ---
REVIEW: https://review.gluster.org/21895 (quotad: fix passing
GF_DATA_TYPE_STR_OLD dict data to v4 protocol) merged (#10) on master by Amar
Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 09:26:26 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 09:26:26 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
Deepshikha khandelwal changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |dkhandel at redhat.com
Resolution|--- |NOTABUG
Last Closed| |2019-03-04 09:26:26
--- Comment #1 from Deepshikha khandelwal ---
Done.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 09:28:55 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 09:28:55 +0000
Subject: [Bugs] [Bug 1684029] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684029
Sanju changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |srakonde at redhat.com
Flags|needinfo?(amukherj at redhat.c |
|om) |
--- Comment #2 from Sanju ---
Root cause:
Commit 5a152a changed the mechanism of computing the checksum. Because of this
change, in heterogeneous cluster, glusterd in upgraded node follows new
mechanism for computing the cksum and non-upgraded nodes follow old mechanism
for computing the cksum. So the cksum in upgraded node doesn't match with
non-upgraded nodes which results in peer rejection issue.
Thanks,
Sanju
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 09:36:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 09:36:31 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
--- Comment #2 from Aravinda VK ---
Thanks
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 10:09:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 10:09:27 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
M. Scherer changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mscherer at redhat.com
Resolution|NOTABUG |CURRENTRELEASE
--- Comment #3 from M. Scherer ---
Wait, what is the plan for that ?
And why isn't gluster-infra in the loop sooner or with more details ?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 11:42:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 11:42:45 +0000
Subject: [Bugs] [Bug 1685120] New: upgrade from 3.12, 4.1 and 5 to 6 broken
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Bug ID: 1685120
Summary: upgrade from 3.12, 4.1 and 5 to 6 broken
Product: GlusterFS
Version: mainline
Status: NEW
Whiteboard: gluster-test-day
Component: core
Severity: urgent
Priority: high
Assignee: bugs at gluster.org
Reporter: srakonde at redhat.com
CC: amukherj at redhat.com, bugs at gluster.org,
hgowtham at redhat.com, pasik at iki.fi, srakonde at redhat.com
Depends On: 1684029
Blocks: 1672818 (glusterfs-6.0)
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1684029 +++
Description of problem:
While trying to upgrade from older versions like 3.12, 4.1 and 5 to gluster 6
RC, the upgrade ends in peer rejected on one node after other.
Version-Release number of selected component (if applicable):
How reproducible:
100%
Steps to Reproduce:
1. create a replica 3 on older versions (3, 4, or 5)
2. kill the gluster process on one node and install gluster 6
3. start glusterd
Actual results:
the new version gets peer rejected. and the brick processes or not started by
glusterd.
Expected results:
peer reject should not happen. Cluster should be healthy.
Additional info:
Status shows the bricks on that particular node alone with N/A as status. Other
nodes aren't visible.
Looks like a volfile mismatch.
The new volfile has "option transport.socket.ssl-enabled off" added while the
old volfile misses it.
The order of quick-read and open-behind are changed in the old and new
versions.
These changes cause the volfile mismatch and mess the cluster.
--- Additional comment from Sanju on 2019-02-28 17:25:57 IST ---
The peers are running inro rejected state because there is a mismatch in the
volfiles. Differences are:
1. Newer volfiles are having "option transport.socket.ssl-enabled off" where
older volfiles are not having this option.
2. order of quick-read and open-behind are changed
commit 4e0fab4 introduced this issue. previously we didn't had any default
value for the option transport.socket.ssl-enabled. So this option was not
captured in the volfile. with the above commit, we are adding a default value.
So this is getting captured in volfile.
commit 4e0fab4 has a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1651059. I feel this commit has
less significance, we can revert this change. If we do so, we are out of 1st
problem.
not sure, why the order of quick-read and open-behind are changed.
Atin, do let me know your thoughts on proposal of reverting the commit 4e0fab4.
Thanks,
Sanju
--- Additional comment from Sanju on 2019-03-04 14:58:55 IST ---
Root cause:
Commit 5a152a changed the mechanism of computing the checksum. Because of this
change, in heterogeneous cluster, glusterd in upgraded node follows new
mechanism for computing the cksum and non-upgraded nodes follow old mechanism
for computing the cksum. So the cksum in upgraded node doesn't match with
non-upgraded nodes which results in peer rejection issue.
Thanks,
Sanju
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1684029
[Bug 1684029] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 11:42:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 11:42:45 +0000
Subject: [Bugs] [Bug 1684029] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684029
Sanju changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1685120
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
[Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon Mar 4 11:42:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 11:42:45 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Sanju changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1685120
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
[Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 14:30:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 14:30:06 +0000
Subject: [Bugs] [Bug 1683574] gluster-server package currently requires the
older userspace-rcu against expectation
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683574
Kaleb KEITHLEY changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kkeithle at redhat.com
--- Comment #1 from Kaleb KEITHLEY ---
The glusterfs-server-6.0-0.1.rc0.el7.x86_64.rpm on
https://buildlogs.centos.org/centos/7/storage/x86_64/gluster-6/ gives me this:
]$ rpm -qpR glusterfs-server-6.0-0.1.rc0.el7.x86_64.rpm| grep rcu
liburcu-bp.so.6()(64bit)
liburcu-cds.so.6()(64bit)
(And the packages haven't been tagged for release yet so there isn't a
glusterfs-server-6.0-0.1.rc0.el7.x86_64.rpm on
http://mirror.centos.org/centos-7/7/storage/x86_64/gluster-6/ yet.)
And the glusterfs.spec file has
BuildRequires: userspace-rcu-devel >= 0.7
so any of a wide range of userspace-rcu packages/libs could potentially satisfy
the BuildRequires.
Where did you get your RPMs from? The Storage SIG builds its own userspace-rcu
package because what's in RHEL/CentOS is too old.
If you're building your own RPMs on your CentOS 7 box and haven't installed the
userspace-rcu* RPMs from the Storage SIG then that's probably why your RPMs
have the incorrect dependency on liburcu-bp.so.1 instead of liburcu-bp.so.6.
The BuildRequires in the .spec should probably be updated to >= 0.10 to prevent
this from happening in the future.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 14:44:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 14:44:14 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Bug 1672818 depends on bug 1683574, which changed state.
Bug 1683574 Summary: gluster-server package currently requires the older userspace-rcu against expectation
https://bugzilla.redhat.com/show_bug.cgi?id=1683574
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |NOTABUG
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 14:44:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 14:44:14 +0000
Subject: [Bugs] [Bug 1683574] gluster-server package currently requires the
older userspace-rcu against expectation
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683574
Kaleb KEITHLEY changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |NOTABUG
Last Closed| |2019-03-04 14:44:14
--- Comment #2 from Kaleb KEITHLEY ---
(In reply to Kaleb KEITHLEY from comment #1)
>
> The BuildRequires in the .spec should probably be updated to >= 0.10 to
> prevent this from happening in the future.
s/should/could/
Since any version of userspace-rcu(-devel) >= 0.7, i.e. liburcu-bp.so.0.1 or
later, is acceptable, it's not incorrect, to build with the older version.
But if you want to build yours with the latest version, you need to install it
from the Storage SIG.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 15:01:00 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 15:01:00 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22297
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 15:19:19 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 15:19:19 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22298
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 15:19:20 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 15:19:20 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #575 from Worker Ant ---
REVIEW: https://review.gluster.org/22298 (packaging: s390x has RDMA support)
posted (#1) for review on master by Kaleb KEITHLEY
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 15:23:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 15:23:14 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
Poornima G changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |pgurusid at redhat.com
Assignee|atumball at redhat.com |pgurusid at redhat.com
Flags| |needinfo?(jsecchiero at enter.
| |eu)
--- Comment #5 from Poornima G ---
Disabling readdir-ahead fixed the issue?
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon Mar 4 15:32:17 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 15:32:17 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
Hubert changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |revirii at googlemail.com
--- Comment #6 from Hubert ---
We seem to have the same problem with a fresh install of glusterfs 5.3 on a
debian stretch. We migrated from an existing setup (version 4.1.6,
distribute-replicate) to a new setup (version 5.3, replicate), and traffic on
clients went up significantly, maybe causing massive iowait on the clients
during high-traffic times. Here are some munin graphs:
network traffic on high iowait client:
https://abload.de/img/client-eth1-traffic76j4i.jpg
network traffic on old servers: https://abload.de/img/oldservers-eth1nejzt.jpg
network traffic on new servers: https://abload.de/img/newservers-eth17ojkf.jpg
performance.readdir-ahead is on by default. I could deactivate it tomorrow
morning (07:00 CEST), and provide tcpdump data if necessary.
Regards,
Hubert
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon Mar 4 16:20:18 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 16:20:18 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
Amye Scavarda changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |MODIFIED
CC| |amye at redhat.com,
| |avishwan at redhat.com
Resolution|CURRENTRELEASE |---
Flags| |needinfo?(avishwan at redhat.c
| |om)
Keywords| |Reopened
--- Comment #4 from Amye Scavarda ---
I have concerns.
What is this for?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Mon Mar 4 19:30:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 19:30:50 +0000
Subject: [Bugs] [Bug 1578405] EIO errors when updating and deleting entries
concurrently
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1578405
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 20025
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon Mar 4 19:31:52 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 04 Mar 2019 19:31:52 +0000
Subject: [Bugs] [Bug 1546649] DHT: Readdir of directory which contain
directory entries is slow
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1546649
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 19559
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 01:30:25 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 01:30:25 +0000
Subject: [Bugs] [Bug 1685337] New: Updating Fedora 28 fail with "Package
glusterfs-5.4-1.fc28.x86_64.rpm is not signed"
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685337
Bug ID: 1685337
Summary: Updating Fedora 28 fail with "Package
glusterfs-5.4-1.fc28.x86_64.rpm is not signed"
Product: GlusterFS
Version: 5
Status: NEW
Component: packaging
Severity: high
Assignee: bugs at gluster.org
Reporter: nsoffer at redhat.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
dnf update fail because glusterfs package are not signed.
# dnf update
...
Package glusterfs-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-libs-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-server-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-fuse-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-devel-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-api-devel-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-api-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-cli-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-client-xlators-5.4-1.fc28.x86_64.rpm is not signed
Package glusterfs-extra-xlators-5.4-1.fc28.x86_64.rpm is not signed
Package python3-gluster-5.4-1.fc28.x86_64.rpm is not signed
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
"dnf clean all" and removing /var/cache/{yum,dnf,PackageKit} does not help.
These are the glusterfs repos are added by ovirt-release-masster from:
http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
[glusterfs-fedora]
name=GlusterFS is a clustered file-system capable of scaling to several
petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/5/LATEST/Fedora/fedora-$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/5/rsa.pub
[glusterfs-noarch-fedora]
name=GlusterFS is a clustered file-system capable of scaling to several
petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/5/LATEST/Fedora/fedora-$releasever/noarch
enabled=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/5/rsa.pub
Version-Release number of selected component (if applicable):
5.4.1
How reproducible:
Always
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 02:49:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 02:49:46 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #576 from Worker Ant ---
REVIEW: https://review.gluster.org/22213 (fuse lock interrupt: fix
flock_interrupt.t) merged (#5) on master by Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 02:50:39 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 02:50:39 +0000
Subject: [Bugs] [Bug 1654021] Gluster volume heal causes continuous info
logging of "invalid argument"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1654021
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-05 02:50:39
--- Comment #4 from Worker Ant ---
REVIEW: https://review.gluster.org/22215 (core: fix volume heal to avoid
\"invalid argument\") merged (#3) on master by Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 03:00:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 03:00:32 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
Aravinda VK changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(avishwan at redhat.c |
|om) |
--- Comment #5 from Aravinda VK ---
This project is for hosting Developer blog posts using Github pages. Developers
are more familiar with Markdown format to write documentation or blog post, so
this will be easy to contribute compared to using UI and write blog posts.
Based on discussion with other developers, they find it difficult to set up a
blog website than writing. This project aims to simplify that
- Official Gluster org blog continue to exists to make announcements or release
highlights or any other blog posts
- This will only host developer blog posts(More technical, developer tips,
feature explanation etc)
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 03:16:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 03:16:14 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22300
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 03:16:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 03:16:15 +0000
Subject: [Bugs] [Bug 1684385] [ovirt-gluster] Rolling gluster upgrade from
3.12.5 to 5.3 led to shard on-disk xattrs disappearing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684385
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #4 from Worker Ant ---
REVIEW: https://review.gluster.org/22300 (dict: handle STR_OLD data type in xdr
conversions) posted (#1) for review on master by Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 04:31:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 04:31:03 +0000
Subject: [Bugs] [Bug 1685051] New Project create request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685051
Amye Scavarda changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|MODIFIED |ASSIGNED
Flags| |needinfo?(avishwan at redhat.c
| |om)
--- Comment #6 from Amye Scavarda ---
This is exactly what should be on gluster.org's blog!
You write wherever you want, we can set WordPress to take Markdown with no
issues.
We should not be duplicating effort when gluster.org is a great platform to be
able to create content on already.
We should get a list of the people who want to write developer blogs and get
them author accounts to publish directly on Gluster.org and publicize from
there through social media.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 07:09:36 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 07:09:36 +0000
Subject: [Bugs] [Bug 1685414] New: glusterd memory usage grows at 98 MB/h
while being monitored by RHGSWA
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Bug ID: 1685414
Summary: glusterd memory usage grows at 98 MB/h while being
monitored by RHGSWA
Product: GlusterFS
Version: mainline
Status: NEW
Component: glusterd
Keywords: Regression
Severity: high
Priority: high
Assignee: bugs at gluster.org
Reporter: moagrawa at redhat.com
CC: amukherj at redhat.com, bmekala at redhat.com,
bugs at gluster.org, dahorak at redhat.com,
mbukatov at redhat.com, nchilaka at redhat.com,
rcyriac at redhat.com, rhs-bugs at redhat.com,
sankarshan at redhat.com, storage-qa-internal at redhat.com,
vbellur at redhat.com
Depends On: 1684648
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684648
[Bug 1684648] glusterd memory usage grows at 98 MB/h while being monitored by
RHGSWA
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 07:10:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 07:10:13 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Mohit Agrawal changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |moagrawa at redhat.com
Summary|glusterd memory usage grows |glusterd memory usage grows
|at 98 MB/h while being |at 98 MB/h while running
|monitored by RHGSWA |"gluster v profile" in a
| |loop
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 07:44:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 07:44:38 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Hubert changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |revirii at googlemail.com
--- Comment #2 from Hubert ---
fyi: happens too when upgrading from 5.3 to 5.4
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 08:03:08 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 08:03:08 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
--- Comment #1 from Mohit Agrawal ---
Hi,
glusterd has memory leak while "gluster v profile info" run in a loop.
To reproduce the same follow below steps
1) Setup 3 1x3 volumes and start the volume
2) Start profile for all the volume
3) Run below command
while [ 1 ]; do pmap -x `pgrep glusterd` | grep total; gluster v profile vol1
info > /dev/null; gluster v profile vol2 info > /dev/null; gluster v profile
vol3 info > /dev/null;sleep 5; done
Thanks,
Mohit Agrawal
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 08:13:18 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 08:13:18 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22301
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 08:13:19 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 08:13:19 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22301 (glusterd: glusterd memory leak while
running \"gluster v profile\" in a loop) posted (#1) for review on master by
MOHIT AGRAWAL
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 09:23:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 09:23:23 +0000
Subject: [Bugs] [Bug 1648768] Tracker bug for all leases related issues
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1648768
--- Comment #20 from Worker Ant ---
REVIEW: https://review.gluster.org/22286 (afr: mark changelog_fsync as
internal) merged (#4) on master by Ravishankar N
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 09:58:47 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 09:58:47 +0000
Subject: [Bugs] [Bug 1670382] parallel-readdir prevents directories and
files listing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670382
--- Comment #4 from Marcin ---
Hello Everyone,
Please, let me know if something has been agreed about the problem?
Thanks in advance
Regards
Marcin
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 11:54:28 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 11:54:28 +0000
Subject: [Bugs] [Bug 1674225] flooding of "dict is NULL" logging & crash of
client process
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1674225
Hubert changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |revirii at googlemail.com
--- Comment #1 from Hubert ---
up to 600.000 log entries here, in a replicate 3 setup.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 12:03:11 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 12:03:11 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
--- Comment #7 from Hubert ---
i set performance.readdir-ahead to off and watched network traffic for about 2
hours now, but traffic is still as high. 5-8 times higher than it was with old
4.1.x volumes.
just curious: i see hundreds of thousands of these messages:
[2019-03-05 12:02:38.423299] W [dict.c:761:dict_ref]
(-->/usr/lib/x86_64-linux-gnu/glusterfs/5.3/xlator/performance/quick-read.so(+0x6df4)
[0x7f0db452edf4]
-->/usr/lib/x86_64-linux-gnu/glusterfs/5.3/xlator/performance/io-cache.so(+0xa39d)
[0x7f0db474039d] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(dict_ref+0x58)
[0x7f0dbb7e4a38] ) 5-dict: dict is NULL [Invalid argument]
see https://bugzilla.redhat.com/show_bug.cgi?id=1674225 - could this be
related?
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 13:56:00 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 13:56:00 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-05 13:56:00
--- Comment #4 from Worker Ant ---
REVIEW: https://review.gluster.org/22238 (io-threads: Prioritize fops with
NO_ROOT_SQUASH pid) merged (#3) on master by Ravishankar N
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 14:26:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 14:26:05 +0000
Subject: [Bugs] [Bug 1685576] New: DNS delegation record for
rhhi-dev.gluster.org
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685576
Bug ID: 1685576
Summary: DNS delegation record for rhhi-dev.gluster.org
Product: GlusterFS
Version: mainline
Status: NEW
Component: project-infrastructure
Assignee: bugs at gluster.org
Reporter: sabose at redhat.com
CC: bugs at gluster.org, gluster-infra at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
Please create DNS delegation record for rhhi-dev.gluster.org
ns-1487.awsdns-57.org.
ns-626.awsdns-14.net.
ns-78.awsdns-09.com.
ns-1636.awsdns-12.co.uk.
Version-Release number of selected component (if applicable):
NA
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 14:45:42 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 14:45:42 +0000
Subject: [Bugs] [Bug 1670382] parallel-readdir prevents directories and
files listing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670382
--- Comment #5 from Nithya Balachandran ---
Hi Marcin,
Sorry, I did not get a chance to look into this. I will try to get someone else
to take a look.
Regards,
Nithya
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 14:52:57 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 14:52:57 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
--- Comment #56 from Nithya Balachandran ---
(In reply to abhays from comment #53)
> (In reply to Nithya Balachandran from comment #51)
> > >
> > >
> > > I don't think so. I would recommend that you debug the tests on your systems
> > > and post patches which will work on both.
> >
> > Please note what I am referring to is for you to look at the .t files and
> > modify file names or remove hardcoding as required.
>
> Yes @Nithya, We understood that you want us to continue debugging the tests
> and provide patches if fix is found.
> While doing the same, we were able to fix the ./tests/bugs/nfs/bug-847622.t
> with the following patch:-
>
> diff --git a/tests/bugs/nfs/bug-847622.t b/tests/bugs/nfs/bug-847622.t
> index 3b836745a..f21884972 100755
> --- a/tests/bugs/nfs/bug-847622.t
> +++ b/tests/bugs/nfs/bug-847622.t
> @@ -28,7 +32,7 @@ cd $N0
>
> # simple getfacl setfacl commands
> TEST touch testfile
> -TEST setfacl -m u:14:r testfile
> +TEST setfacl -m u:14:r $B0/brick0/testfile
> TEST getfacl testfile
>
> Please check, if the above patch can be merged.
>
>
This fix is incorrect. The patch changes the test to modify the brick directly
while the test is to check that these operations succeed on the mount. You need
to see why it fails and then we can figure out the fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 14:56:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 14:56:46 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-03-05 14:56:46
--- Comment #3 from Worker Ant ---
REVIEW: https://review.gluster.org/22301 (glusterd: glusterd memory leak while
running \"gluster v profile\" in a loop) merged (#3) on master by Atin
Mukherjee
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 15:05:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 15:05:32 +0000
Subject: [Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672480
--- Comment #57 from Nithya Balachandran ---
(In reply to abhays from comment #55)
> (In reply to Nithya Balachandran from comment #54)
> > >
> > > However, the test cases are still failing and only pass if x86 hash values
> > > are provided(Refer to comment#8):-
> > > ./tests/bugs/glusterfs/bug-902610.t
> > > ./tests/bugs/posix/bug-1619720.t
> >
> > Please provide more information on what changes you tried.
>
> For tests/bugs/glusterfs/bug-902610.t:-
> In the test case, after the kill_brick function is run, the mkdir $M0/dir1
> doesn't work and hence the get_layout function test fails. So,as a
> workaround we tried not killing the brick and then checked the functionality
> of the test case, after which the dir1 did get created in all the 4 bricks,
> however, the test failed with the following output:-
The mkdir function will fail if the hashed brick of the directory being created
is down. In your case, the change in hashed values means the brick that was
killed is the hashed subvol for the directory. Killing a different brick
should cause it to succeed.
In any case this is not a feature that we support anymore so I can just remove
the test case.
> Therefore, can these changes be added in the test case with a condition for
> s390x separately?
I do not think we should separate it out like this. The better way would be to
just find 2 bricks that work for both big and little endian.
I will try out your changes on a big endian system and see if this combination
will work there as well.
>
> Also, We have a few queries on the tests behaviour.
> When a directory or a file gets created, according to me, it should be
> placed in the brick depending on its hash range and value of the
> file/directory.
> However, in the above test, as you can see, if we don't kill the
> bricks{2,3}, the directory gets created in all the bricks{0,1,2,3}.So, does
> it not consider hash values and range at this point or is it something to do
> with mounting FUSE?
The way dht creates files and directories is slightly different.
For files, it calculates the hash and creates it in the subvolume in whose
directory layout range it falls.
For directories, it first tries to create it on the hashed subvol. If for some
reason that fails, it will not be created on the other bricks. In this test,
for s390x, one of the bricks killed was the hashed subvol so mkdir fails.
The solution here is to make sure the bricks being killed are not the hashed
subvol in either big or little endian systems.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 15:06:42 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 15:06:42 +0000
Subject: [Bugs] [Bug 1685576] DNS delegation record for rhhi-dev.gluster.org
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685576
M. Scherer changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mscherer at redhat.com
--- Comment #1 from M. Scherer ---
For the context, that's for a test instance of openshift hosted on AWS.
The delegation got created, please tell me if ther eis any issue
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 15:28:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 15:28:38 +0000
Subject: [Bugs] [Bug 1685023] FD processes for larger files are not closed
soon after FOP finished
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685023
david.spisla at iternity.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|bitrot |core
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the Docs Contact for the bug.
From bugzilla at redhat.com Tue Mar 5 15:46:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 15:46:23 +0000
Subject: [Bugs] [Bug 1684569] Upgrade from 4.1 and 5 is broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
Sanju changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #2 from Sanju ---
upstream patch: https://review.gluster.org/#/c/glusterfs/+/22297/
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 16:00:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 16:00:02 +0000
Subject: [Bugs] [Bug 1670382] parallel-readdir prevents directories and
files listing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670382
Poornima G changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pgurusid at redhat.com
Flags| |needinfo?(locbus at gmail.com)
--- Comment #6 from Poornima G ---
So the files don't appear even on the bricks is it? That's very strange. Did
you check on both the servers and all the 6 bricks. We will try to check if the
issue is seen even on fuse mount or is it only specific to samba access.Can you
try the following steps and let us know the output:
Create two temporary fuse mounts and create a file and directory from one mount
point. List it on the same mount, Do you see the file and directory? List it on
the other mount too, are the files visible?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 16:01:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 16:01:46 +0000
Subject: [Bugs] [Bug 1670382] parallel-readdir prevents directories and
files listing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670382
Poornima G changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
QA Contact| |pgurusid at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 17:49:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 17:49:41 +0000
Subject: [Bugs] [Bug 1648768] Tracker bug for all leases related issues
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1648768
--- Comment #21 from Worker Ant ---
REVIEW: https://review.gluster.org/22287 (leases: Do not process internal fops)
merged (#4) on master by Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue Mar 5 18:16:55 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 18:16:55 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22302
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 18:16:55 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 18:16:55 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1193929
--- Comment #577 from Worker Ant ---
REVIEW: https://review.gluster.org/22302 (core: avoid dynamic TLS allocation
when possible) posted (#2) for review on master by Xavi Hernandez
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 18:56:54 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 18:56:54 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Artem Russakovskii changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |archon810 at gmail.com
--- Comment #3 from Artem Russakovskii ---
Noticed the same when upgrading from 5.3 to 5.4, as mentioned.
I'm confused though. Is actual replication affected, because the 5.4 server and
the 3x 5.3 servers still show heal info as all 4 connected, and the files seem
to be replicating correctly as well.
So what's actually affected - just the status command? Is it fixable by
tweaking transport.socket.ssl-enabled? Does upgrading all servers to 5.4
resolve it, or should we revert back to 5.3?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Tue Mar 5 19:09:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 05 Mar 2019 19:09:34 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
--- Comment #4 from Artem Russakovskii ---
Ended up downgrading to 5.3 just in case. Peer status and volume status are OK
now.
zypper install --oldpackage glusterfs-5.3-lp150.100.1
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: glusterfs-5.3-lp150.100.1.x86_64 requires libgfapi0 = 5.3, but this
requirement cannot be provided
not installable providers: libgfapi0-5.3-lp150.100.1.x86_64[glusterfs]
Solution 1: Following actions will be done:
downgrade of libgfapi0-5.4-lp150.100.1.x86_64 to
libgfapi0-5.3-lp150.100.1.x86_64
downgrade of libgfchangelog0-5.4-lp150.100.1.x86_64 to
libgfchangelog0-5.3-lp150.100.1.x86_64
downgrade of libgfrpc0-5.4-lp150.100.1.x86_64 to
libgfrpc0-5.3-lp150.100.1.x86_64
downgrade of libgfxdr0-5.4-lp150.100.1.x86_64 to
libgfxdr0-5.3-lp150.100.1.x86_64
downgrade of libglusterfs0-5.4-lp150.100.1.x86_64 to
libglusterfs0-5.3-lp150.100.1.x86_64
Solution 2: do not install glusterfs-5.3-lp150.100.1.x86_64
Solution 3: break glusterfs-5.3-lp150.100.1.x86_64 by ignoring some of its
dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): 1
Resolving dependencies...
Resolving package dependencies...
The following 6 packages are going to be downgraded:
glusterfs libgfapi0 libgfchangelog0 libgfrpc0 libgfxdr0 libglusterfs0
6 packages to downgrade.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 02:14:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 02:14:12 +0000
Subject: [Bugs] [Bug 1685771] New: glusterd memory usage grows at 98 MB/h
while being monitored by RHGSWA
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
Bug ID: 1685771
Summary: glusterd memory usage grows at 98 MB/h while being
monitored by RHGSWA
Product: GlusterFS
Version: 6
Status: NEW
Component: glusterd
Keywords: Regression
Severity: high
Priority: high
Assignee: bugs at gluster.org
Reporter: moagrawa at redhat.com
CC: amukherj at redhat.com, bmekala at redhat.com,
bugs at gluster.org, dahorak at redhat.com,
mbukatov at redhat.com, nchilaka at redhat.com,
rcyriac at redhat.com, rhs-bugs at redhat.com,
sankarshan at redhat.com, storage-qa-internal at redhat.com,
vbellur at redhat.com
Depends On: 1684648
Blocks: 1685414
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684648
[Bug 1684648] glusterd memory usage grows at 98 MB/h while being monitored by
RHGSWA
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
[Bug 1685414] glusterd memory usage grows at 98 MB/h while running "gluster v
profile" in a loop
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 02:14:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 02:14:12 +0000
Subject: [Bugs] [Bug 1685414] glusterd memory usage grows at 98 MB/h while
running "gluster v profile" in a loop
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685414
Mohit Agrawal changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1685771
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
[Bug 1685771] glusterd memory usage grows at 98 MB/h while being monitored by
RHGSWA
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 02:14:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 02:14:38 +0000
Subject: [Bugs] [Bug 1685771] glusterd memory usage grows at 98 MB/h while
being monitored by RHGSWA
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
Mohit Agrawal changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |moagrawa at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 02:30:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 02:30:14 +0000
Subject: [Bugs] [Bug 1685771] glusterd memory usage grows at 98 MB/h while
being monitored by RHGSWA
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22303
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 02:30:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 02:30:15 +0000
Subject: [Bugs] [Bug 1685771] glusterd memory usage grows at 98 MB/h while
being monitored by RHGSWA
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22303 (glusterd: glusterd memory leak while
running \"gluster v profile\" in a loop) posted (#2) for review on release-6 by
MOHIT AGRAWAL
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 03:16:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:16:05 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22304
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 03:16:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:16:06 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |POST
Resolution|NEXTRELEASE |---
Keywords| |Reopened
--- Comment #5 from Worker Ant ---
REVIEW: https://review.gluster.org/22304 (io-threads: Prioritize fops with
NO_ROOT_SQUASH pid) posted (#1) for review on release-6 by Susant Palai
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 03:18:29 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:18:29 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
--- Comment #6 from Worker Ant ---
REVISION POSTED: https://review.gluster.org/22304 (io-threads: Prioritize fops
with NO_ROOT_SQUASH pid) posted (#2) for review on release-6 by Susant Palai
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 03:18:30 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:18:30 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID|Gluster.org Gerrit 22304 |
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 03:18:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:18:31 +0000
Subject: [Bugs] [Bug 1676429] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676429
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22304
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 03:18:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:18:32 +0000
Subject: [Bugs] [Bug 1676429] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676429
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22304 (io-threads: Prioritize fops with
NO_ROOT_SQUASH pid) posted (#2) for review on release-6 by Susant Palai
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 03:24:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 03:24:43 +0000
Subject: [Bugs] [Bug 1676430] distribute: Perf regression in mkdir path
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1676430
Susant Kumar Palai changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed|2019-03-05 13:56:00 |2019-03-06 03:24:43
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 05:49:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 05:49:03 +0000
Subject: [Bugs] [Bug 1685576] DNS delegation record for rhhi-dev.gluster.org
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685576
Rohan CJ changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rojoseph at redhat.com
Flags| |needinfo?(mscherer at redhat.c
| |om)
--- Comment #2 from Rohan CJ ---
The delegation doesn't seem to be working. I don't know if DNS propagation is a
concern here, but I did also try directly querying ns1.redhat.com.
Here is the link to the kind of delegation we want for openshift:
https://github.com/openshift/installer/blob/master/docs/user/aws/route53.md#step-4b-subdomain---perform-dns-delegation
$ dig rhhi-dev.gluster.org
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-13.P2.fc28 <<>> rhhi-dev.gluster.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18531
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rhhi-dev.gluster.org. IN A
;; AUTHORITY SECTION:
gluster.org. 278 IN SOA ns1.redhat.com. noc.redhat.com.
2019030501 3600 1800 604800 86400
;; Query time: 81 msec
;; SERVER: 10.68.5.26#53(10.68.5.26)
;; WHEN: Wed Mar 06 11:12:41 IST 2019
;; MSG SIZE rcvd: 103
$ dig @ns-1487.awsdns-57.org. rhhi-dev.gluster.org
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-13.P2.fc28 <<>> @ns-1487.awsdns-57.org.
rhhi-dev.gluster.org
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58544
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rhhi-dev.gluster.org. IN A
;; AUTHORITY SECTION:
rhhi-dev.gluster.org. 900 IN SOA ns-1487.awsdns-57.org.
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 39 msec
;; SERVER: 205.251.197.207#53(205.251.197.207)
;; WHEN: Wed Mar 06 11:13:27 IST 2019
;; MSG SIZE rcvd: 131
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 07:35:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 07:35:31 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Sunil Kumar Acharya changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sheggodu at redhat.com
Depends On| |1685771, 1511779
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1511779
[Bug 1511779] Garbage collect inactive inodes in fuse-bridge
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
[Bug 1685771] glusterd memory usage grows at 98 MB/h while being monitored by
RHGSWA
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 07:35:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 07:35:31 +0000
Subject: [Bugs] [Bug 1685771] glusterd memory usage grows at 98 MB/h while
being monitored by RHGSWA
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685771
Sunil Kumar Acharya changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1672818 (glusterfs-6.0)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 07:50:10 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 07:50:10 +0000
Subject: [Bugs] [Bug 1685813] New: Not able to run centos-regression getting
exception error
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685813
Bug ID: 1685813
Summary: Not able to run centos-regression getting exception
error
Product: GlusterFS
Version: 6
Status: NEW
Component: project-infrastructure
Assignee: bugs at gluster.org
Reporter: moagrawa at redhat.com
CC: bugs at gluster.org, gluster-infra at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
Not able to run centos-regression build is getting an Exception error
Version-Release number of selected component (if applicable):
How reproducible:
https://build.gluster.org/job/centos7-regression/5017/consoleFull
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 08:00:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 08:00:12 +0000
Subject: [Bugs] [Bug 1670382] parallel-readdir prevents directories and
files listing
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1670382
Marcin changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(locbus at gmail.com) |
--- Comment #7 from Marcin ---
In terms of the visibility of files directly on the bricks of the server, I've
described this a bit imprecisely. The files aren't visible at the point of
mounting the entire gluster resource at the server OS level - /glusterfs was
really mounted by native client and in this way "fuse mount" has been checked
as well (there is an entry in a fstab file i.e. /glusterfs and mount type is
fuse.glusterfs). Of course, they are visible at the level of individual bricks.
I apologize for the inaccuracy.
In my spare time, I'll try to do a bit more thorough tests to show you the
result.
I'll be grateful for your commitment.
Regards
Marcin
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 09:29:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 09:29:38 +0000
Subject: [Bugs] [Bug 1685576] DNS delegation record for rhhi-dev.gluster.org
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685576
M. Scherer changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(mscherer at redhat.c |
|om) |
--- Comment #3 from M. Scherer ---
Seems there is a issue with the DNS server, as it work, but only on the
internal server in the RH lan. I am slightly puzzled on that. I will have to
escalate that to IT.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 09:45:53 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 09:45:53 +0000
Subject: [Bugs] [Bug 1685813] Not able to run centos-regression getting
exception error
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685813
M. Scherer changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mscherer at redhat.com
--- Comment #1 from M. Scherer ---
Yeah, there is a patch that seems to break builders one by one.
Dkhandel told me this morning that we lost lots of aws builder (8 out of 10),
and upon investigation, they all ran regression tests for that change before
becoming offline:
https://review.gluster.org/#/c/glusterfs/+/22290/
As said on gerrit, I strongly suspect that the logic change do result in the
test spawning a infinite loop, since the builder we recovered didn't show any
trace of error in the log, which is the kind of symptom you get with a infinite
loop (while still answering to ping, since icmp is handled in the kernel).
So I would suggest to investigate ./tests/00-geo-rep/00-georep-verify-setup.t ,
as I see that as being the last test run before losing contact with builders.
In fact, since the patch worked for the 2nd iteration, I guess the issue is the
3rd iteration of the patch.
In any case, I think that's not a infra issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 09:54:26 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 09:54:26 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
Jacob changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(jsecchiero at enter. |
|eu) |
--- Comment #8 from Jacob ---
Disabling readdir-ahead doesn't change the througput.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 10:07:59 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 10:07:59 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
--- Comment #9 from Alberto Bengoa ---
Neither to me.
BTW, read-ahead/readdir-ahead shouldn't generate traffic in the opposite
direction? ( Server -> Client)
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 10:53:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 10:53:31 +0000
Subject: [Bugs] [Bug 1685813] Not able to run centos-regression getting
exception error
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685813
--- Comment #2 from M. Scherer ---
I did reboot the broken builders and they are back. And I also looked at the
patch, but didn't found something, so I suspect there is some logic that escape
me.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 10:58:53 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 10:58:53 +0000
Subject: [Bugs] [Bug 1685813] Not able to run centos-regression getting
exception error
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685813
--- Comment #3 from Mohit Agrawal ---
Thanks, Michael there is some issue in my patch.
I will upload a new patch.
You can close the bugzilla.
Thanks,
Mohit Agrawal
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 11:20:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 11:20:38 +0000
Subject: [Bugs] [Bug 1685944] New: WORM-XLator: Maybe integer overflow when
computing new atime
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685944
Bug ID: 1685944
Summary: WORM-XLator: Maybe integer overflow when computing new
atime
Product: GlusterFS
Version: mainline
Status: NEW
Component: core
Assignee: bugs at gluster.org
Reporter: david.spisla at iternity.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
May integer overflow in WORM Xlator possibly.
The structs:
typedef struct {
uint8_t worm : 1;
uint8_t retain : 1;
uint8_t legal_hold : 1;
uint8_t ret_mode : 1;
int64_t ret_period;
int64_t auto_commit_period;
} worm_reten_state_t;
typedef struct {
gf_boolean_t readonly_or_worm_enabled;
gf_boolean_t worm_file;
gf_boolean_t worm_files_deletable;
int64_t reten_period;
int64_t com_period;
int reten_mode;
time_t start_time;
} read_only_priv_t;
from read-only.h are using uint64_t values to store periods of retention and
autocommmit. This seems to be dangerous since in worm-helper.c the function
worm_set_state computes in line 97:
stbuf->ia_atime = time(NULL) + retention_state->ret_period;
stbuf->ia_atime is using int64_t because auf the settings of struct iattr. So
if there is a very very high retention period stored , there is maybe an
integer overflow.
What can be the solution? Using int64_t instead if uint64_t may reduce the
probability of the occurance.
Version-Release number of selected component (if applicable):
Gluster v5.4
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 11:28:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 11:28:23 +0000
Subject: [Bugs] [Bug 1685944] WORM-XLator: Maybe integer overflow when
computing new atime
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685944
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22309
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 11:40:49 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 11:40:49 +0000
Subject: [Bugs] [Bug 1673058] Network throughput usage increased x5
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1673058
--- Comment #10 from Nithya Balachandran ---
(In reply to Jacob from comment #4)
> i'm not able to upload in the bugzilla portal due to the size of the pcap.
> You can download from here:
>
> https://mega.nz/#!FNY3CS6A!70RpciIzDgNWGwbvEwH-_b88t9e1QVOXyLoN09CG418
@Poornima,
the following are the calls and instances from the above:
104 proc-1 (stat)
8259 proc-11 (open)
46 proc-14 (statfs)
8239 proc-15 (flush)
8 proc-18 (getxattr)
68 proc-2 (readlink)
5576 proc-27 (lookup)
8388 proc-41 (forget)
Not sure if it helps.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 12:19:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 12:19:13 +0000
Subject: [Bugs] [Bug 1663519] Memory leak when smb.conf has "store dos
attributes = yes"
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1663519
--- Comment #3 from ryan at magenta.tv ---
Hello,
Could you advise if there is any update on this?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 12:24:10 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 12:24:10 +0000
Subject: [Bugs] [Bug 1313567] flooding of "dict is NULL" logging
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1313567
--- Comment #23 from ryan at magenta.tv ---
Hello,
Is there any progress with this?
We've had multiple systems consume the entire root volume due to the log file
filling the volume.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 14:19:52 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 14:19:52 +0000
Subject: [Bugs] [Bug 1674225] flooding of "dict is NULL" logging & crash of
client process
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1674225
--- Comment #2 from Hubert ---
just wanted to mention that these log entries appear in a fresh 5.3 install, so
no upgrade from a previous glusterfs version here.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 14:25:09 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 14:25:09 +0000
Subject: [Bugs] [Bug 1686009] New: gluster fuse crashed with segmentation
fault possibly due to dentry not found
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686009
Bug ID: 1686009
Summary: gluster fuse crashed with segmentation fault possibly
due to dentry not found
Product: GlusterFS
Version: mainline
Status: NEW
Component: core
Keywords: ZStream
Severity: urgent
Priority: high
Assignee: atumball at redhat.com
Reporter: atumball at redhat.com
CC: bmekala at redhat.com, bugs at gluster.org,
jahernan at redhat.com, nbalacha at redhat.com,
nchilaka at redhat.com, pkarampu at redhat.com,
rcyriac at redhat.com, rgowdapp at redhat.com,
rhs-bugs at redhat.com, sankarshan at redhat.com,
srangana at redhat.com, vbellur at redhat.com
Depends On: 1685078
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1685078 +++
Description of problem:
=====================
was performing some non-functional tests for testing rpc fixes and found that
one of the fuse clients crashed as below
[2019-03-01 13:37:02.398653] I [dict.c:471:dict_get]
(-->/usr/lib64/glusterfs/3.12.2/xlator/cluster/replicate.so(+0x6228d)
[0x7f5147de128d]
-->/usr/lib64/glusterfs/3.12.2/xlator/cluster/distribute.so(+0x202f7)
[0x7f5147afc2f7] -->/lib64/libglusterfs.so.0(dict_get+0x10c) [0x7f515a5b2d3c] )
13-dict: !this || key=trusted.glusterfs.dht.mds [Invalid argument]
[2019-03-01 13:37:02.711187] W [inode.c:197:__is_dentry_hashed]
(-->/lib64/libglusterfs.so.0(__inode_path+0x68) [0x7f515a5cd1c8]
-->/lib64/libglusterfs.so.0(+0x3add4) [0x7f515a5cadd4]
-->/lib64/libglusterfs.so.0(+0x3ad7e) [0x7f515a5cad7e] ) 0-fuse: dentry not
found
pending frames:
frame : type(1) op(UNLINK)
frame : type(1) op(UNLINK)
frame : type(1) op(READDIRP)
frame : type(1) op(OPEN)
frame : type(1) op(STAT)
frame : type(0) op(0)
frame : type(0) op(0)
patchset: git://git.gluster.org/glusterfs.git
signal received: 11
time of crash:
2019-03-01 13:37:02
configuration details:
argp 1
backtrace 1
dlfcn 1
libpthread 1
llistxattr 1
setfsid 1
spinlock 1
epoll.h 1
xattr.h 1
st_atim.tv_nsec 1
package-string: glusterfs 3.12.2
/lib64/libglusterfs.so.0(_gf_msg_backtrace_nomem+0x9d)[0x7f515a5bbb9d]
/lib64/libglusterfs.so.0(gf_print_trace+0x334)[0x7f515a5c6114]
/lib64/libc.so.6(+0x36280)[0x7f5158bf8280]
/lib64/libglusterfs.so.0(+0x3adc2)[0x7f515a5cadc2]
/lib64/libglusterfs.so.0(__inode_path+0x68)[0x7f515a5cd1c8]
/lib64/libglusterfs.so.0(inode_path+0x31)[0x7f515a5cd551]
/lib64/libglusterfs.so.0(loc_touchup+0x7a)[0x7f515a5b9dba]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x6f8b)[0x7f515196df8b]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x7665)[0x7f515196e665]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x7bbd)[0x7f515196ebbd]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x7c8e)[0x7f515196ec8e]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x7cd0)[0x7f515196ecd0]
/usr/lib64/glusterfs/3.12.2/xlator/mount/fuse.so(+0x1f702)[0x7f5151986702]
/lib64/libpthread.so.0(+0x7dd5)[0x7f51593f7dd5]
/lib64/libc.so.6(clone+0x6d)[0x7f5158cbfead]
---------
warning: core file may not match specified executable file.
Reading symbols from /usr/sbin/glusterfsd...Reading symbols from
/usr/lib/debug/usr/sbin/glusterfsd.debug...done.
done.
Missing separate debuginfo for
Try: yum --enablerepo='*debug*' install
/usr/lib/debug/.build-id/73/3d1c681cfbd8bbeb11e8b7f80876a9aed6bb74
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/glusterfs
--volfile-server=my-machine.redhat.com --volf'.
Program terminated with signal 11, Segmentation fault.
#0 __dentry_search_arbit (inode=inode at entry=0x7f50ec000e98) at inode.c:1450
1450 list_for_each_entry (trav, &inode->dentry_list, inode_list) {
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-260.el7_6.3.x86_64 keyutils-libs-1.5.8-3.el7.x86_64
krb5-libs-1.15.1-37.el7_6.x86_64 libcom_err-1.42.9-13.el7.x86_64
libgcc-4.8.5-36.el7.x86_64 libselinux-2.5-14.1.el7.x86_64
libuuid-2.23.2-59.el7.x86_64 openssl-libs-1.0.2k-16.el7.x86_64
pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) bt
#0 __dentry_search_arbit (inode=inode at entry=0x7f50ec000e98) at inode.c:1450
#1 0x00007f515a5cd1c8 in __inode_path (inode=inode at entry=0x7f50dc01dfc8,
name=name at entry=0x0, bufp=bufp at entry=0x7f5145ed6d30) at inode.c:1551
#2 0x00007f515a5cd551 in inode_path (inode=0x7f50dc01dfc8,
name=name at entry=0x0, bufp=bufp at entry=0x7f5145ed6d30) at inode.c:1642
#3 0x00007f515a5b9dba in loc_touchup (loc=0x7f5069ee43c0, name=) at xlator.c:880
#4 0x00007f515196df8b in fuse_resolve_loc_touchup (state=0x7f5069ee43a0) at
fuse-resolve.c:33
#5 fuse_resolve_continue (state=0x7f5069ee43a0) at fuse-resolve.c:704
#6 0x00007f515196e665 in fuse_resolve_inode (state=0x7f5069ee43a0) at
fuse-resolve.c:364
#7 0x00007f515196ebbd in fuse_resolve (state=0x7f5069ee43a0) at
fuse-resolve.c:651
#8 0x00007f515196ec8e in fuse_resolve_all (state=) at
fuse-resolve.c:679
#9 0x00007f515196ecd0 in fuse_resolve_and_resume (state=0x7f5069ee43a0,
fn=0x7f5151972c10 ) at fuse-resolve.c:718
#10 0x00007f5151986702 in fuse_thread_proc (data=0x563689a35f10) at
fuse-bridge.c:5781
#11 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f5158cbfead in clone () from /lib64/libc.so.6
(gdb) t a a bt
Thread 11 (Thread 0x7f515aaa6780 (LWP 4229)):
#0 0x00007f51593f8f47 in pthread_join () from /lib64/libpthread.so.0
#1 0x00007f515a61af78 in event_dispatch_epoll (event_pool=0x563689a2e250) at
event-epoll.c:846
#2 0x0000563687bed538 in main (argc=4, argv=) at
glusterfsd.c:2692
Thread 10 (Thread 0x7f51456d6700 (LWP 4257)):
#0 0x00007f51593fb965 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f515197039b in timed_response_loop (data=0x563689a35f10) at
fuse-bridge.c:4660
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x7f514cc97700 (LWP 4251)):
#0 0x00007f5158cc0483 in epoll_wait () from /lib64/libc.so.6
#1 0x00007f515a61a6e8 in event_dispatch_epoll_worker (data=0x563689a8bd60) at
event-epoll.c:749
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x7f514d498700 (LWP 4250)):
#0 0x00007f5158cc0483 in epoll_wait () from /lib64/libc.so.6
#1 0x00007f515a61a6e8 in event_dispatch_epoll_worker (data=0x563689a8ba90) at
event-epoll.c:749
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x7f5150163700 (LWP 4234)):
#0 0x00007f51593fbd12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f515a5f7dd8 in syncenv_task (proc=proc at entry=0x563689a49b20) at
syncop.c:603
#2 0x00007f515a5f8ca0 in syncenv_processor (thdata=0x563689a49b20) at
syncop.c:695
#3 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f5151165700 (LWP 4231)):
#0 0x00007f51593ff361 in sigwait () from /lib64/libpthread.so.0
#1 0x0000563687bf0c7b in glusterfs_sigwaiter (arg=) at
glusterfsd.c:2242
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f51322ff700 (LWP 22247)):
#0 0x00007f51593fbd12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f515a5f7dd8 in syncenv_task (proc=proc at entry=0x563689a4a2a0) at
syncop.c:603
#2 0x00007f515a5f8ca0 in syncenv_processor (thdata=0x563689a4a2a0) at
syncop.c:695
#3 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f5150964700 (LWP 4232)):
#0 0x00007f5158c86e2d in nanosleep () from /lib64/libc.so.6
#1 0x00007f5158c86cc4 in sleep () from /lib64/libc.so.6
#2 0x00007f515a5e4b9d in pool_sweeper (arg=) at mem-pool.c:470
#3 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f5144ed5700 (LWP 4258)):
#0 0x00007f51593fb965 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f51519708d3 in notify_kernel_loop (data=) at
fuse-bridge.c:4584
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f5151966700 (LWP 4230)):
#0 0x00007f51593fee3d in nanosleep () from /lib64/libpthread.so.0
#1 0x00007f515a5c9f86 in gf_timer_proc (data=0x563689a49300) at timer.c:174
#2 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f5158cbfead in clone () from /lib64/libc.so.6
---Type to continue, or q to quit---
Thread 1 (Thread 0x7f5145ed7700 (LWP 4256)):
#0 __dentry_search_arbit (inode=inode at entry=0x7f50ec000e98) at inode.c:1450
#1 0x00007f515a5cd1c8 in __inode_path (inode=inode at entry=0x7f50dc01dfc8,
name=name at entry=0x0, bufp=bufp at entry=0x7f5145ed6d30) at inode.c:1551
#2 0x00007f515a5cd551 in inode_path (inode=0x7f50dc01dfc8,
name=name at entry=0x0, bufp=bufp at entry=0x7f5145ed6d30) at inode.c:1642
#3 0x00007f515a5b9dba in loc_touchup (loc=0x7f5069ee43c0, name=) at xlator.c:880
#4 0x00007f515196df8b in fuse_resolve_loc_touchup (state=0x7f5069ee43a0) at
fuse-resolve.c:33
#5 fuse_resolve_continue (state=0x7f5069ee43a0) at fuse-resolve.c:704
#6 0x00007f515196e665 in fuse_resolve_inode (state=0x7f5069ee43a0) at
fuse-resolve.c:364
#7 0x00007f515196ebbd in fuse_resolve (state=0x7f5069ee43a0) at
fuse-resolve.c:651
#8 0x00007f515196ec8e in fuse_resolve_all (state=) at
fuse-resolve.c:679
#9 0x00007f515196ecd0 in fuse_resolve_and_resume (state=0x7f5069ee43a0,
fn=0x7f5151972c10 ) at fuse-resolve.c:718
#10 0x00007f5151986702 in fuse_thread_proc (data=0x563689a35f10) at
fuse-bridge.c:5781
#11 0x00007f51593f7dd5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f5158cbfead in clone () from /lib64/libc.so.6
(gdb) q
################# on another client too hit same crash ##########
sing host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/glusterfs --acl
--volfile-server=my-machine.redhat.com'.
Program terminated with signal 11, Segmentation fault.
#0 __dentry_search_arbit (inode=inode at entry=0x7f0a5002eab8) at inode.c:1450
1450 list_for_each_entry (trav, &inode->dentry_list, inode_list) {
Missing separate debuginfos, use: debuginfo-install
glusterfs-fuse-3.12.2-43.el7.x86_64
(gdb) bt
#0 __dentry_search_arbit (inode=inode at entry=0x7f0a5002eab8) at inode.c:1450
#1 0x00007f0ac23a01c8 in __inode_path (inode=inode at entry=0x7f0a50009e68,
name=name at entry=0x7f0a028f1b50 "fresh_top.log",
bufp=bufp at entry=0x7f0985ba36e8)
at inode.c:1551
#2 0x00007f0ac23a0551 in inode_path (inode=0x7f0a50009e68,
name=0x7f0a028f1b50 "fresh_top.log", bufp=bufp at entry=0x7f0985ba36e8)
at inode.c:1642
#3 0x00007f0ab9740489 in fuse_resolve_entry (state=0x7f0985ba3570) at
fuse-resolve.c:99
#4 0x00007f0ab974162d in fuse_resolve_parent
(state=state at entry=0x7f0985ba3570) at fuse-resolve.c:312
#5 0x00007f0ab9741998 in fuse_resolve (state=0x7f0985ba3570) at
fuse-resolve.c:647
#6 0x00007f0ab9741c8e in fuse_resolve_all (state=) at
fuse-resolve.c:679
#7 0x00007f0ab9741cd0 in fuse_resolve_and_resume (state=0x7f0985ba3570,
fn=0x7f0ab9744e40 )
at fuse-resolve.c:718
---Type to continue, or q to quit---
#8 0x00007f0ab9759702 in fuse_thread_proc (data=0x559b1ebcf0c0) at
fuse-bridge.c:5781
#9 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
(gdb) t a a bt
Thread 11 (Thread 0x7f0ac2879780 (LWP 4246)):
#0 0x00007f0ac11cbf47 in pthread_join () from /lib64/libpthread.so.0
#1 0x00007f0ac23edf78 in event_dispatch_epoll (event_pool=0x559b1ebc7250) at
event-epoll.c:846
#2 0x0000559b1de33538 in main (argc=5, argv=) at
glusterfsd.c:2692
Thread 10 (Thread 0x7f0aad2ae700 (LWP 4260)):
#0 0x00007f0ac11ce965 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f0ab974339b in timed_response_loop (data=0x559b1ebcf0c0) at
fuse-bridge.c:4660
#2 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x7f0ab7f36700 (LWP 4251)):
---Type to continue, or q to quit---
#0 0x00007f0ac11ced12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f0ac23cadd8 in syncenv_task (proc=proc at entry=0x559b1ebe2e40) at
syncop.c:603
#2 0x00007f0ac23cbca0 in syncenv_processor (thdata=0x559b1ebe2e40) at
syncop.c:695
#3 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x7f0ab8737700 (LWP 4250)):
#0 0x00007f0ac0a59e2d in nanosleep () from /lib64/libc.so.6
#1 0x00007f0ac0a59cc4 in sleep () from /lib64/libc.so.6
#2 0x00007f0ac23b7b9d in pool_sweeper (arg=) at mem-pool.c:470
#3 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
---Type to continue, or q to quit---
Thread 7 (Thread 0x7f0ab9739700 (LWP 4248)):
#0 0x00007f0ac11d1e3d in nanosleep () from /lib64/libpthread.so.0
#1 0x00007f0ac239cf86 in gf_timer_proc (data=0x559b1ebe2620) at timer.c:174
#2 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f0ab4a6a700 (LWP 4256)):
#0 0x00007f0ac11d14ed in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0ac11ccdcb in _L_lock_883 () from /lib64/libpthread.so.0
#2 0x00007f0ac11ccc98 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0ac239eee9 in inode_unref (inode=0x7f09850f0d98) at inode.c:668
#4 0x00007f0ac238ca02 in loc_wipe (loc=loc at entry=0x7f09865af178) at
xlator.c:768
#5 0x00007f0ab40231ee in client_local_wipe (local=local at entry=0x7f09865af178)
at client-helpers.c:127
---Type to continue, or q to quit---
#6 0x00007f0ab4032f0d in client3_3_lookup_cbk (req=,
iov=, count=,
myframe=0x7f098676f668) at client-rpc-fops.c:2872
#7 0x00007f0ac2134a00 in rpc_clnt_handle_reply
(clnt=clnt at entry=0x7f097ca19cb0, pollin=pollin at entry=0x7f097ccffd50)
at rpc-clnt.c:778
#8 0x00007f0ac2134d6b in rpc_clnt_notify (trans=,
mydata=0x7f097ca19ce0, event=,
data=0x7f097ccffd50) at rpc-clnt.c:971
#9 0x00007f0ac2130ae3 in rpc_transport_notify (this=this at entry=0x7f098e451610,
event=event at entry=RPC_TRANSPORT_MSG_RECEIVED,
data=data at entry=0x7f097ccffd50) at rpc-transport.c:557
#10 0x00007f0ab6d22586 in socket_event_poll_in (this=this at entry=0x7f098e451610,
notify_handled=)
at socket.c:2322
#11 0x00007f0ab6d24bca in socket_event_handler (fd=33, idx=26, gen=4,
data=0x7f098e451610, poll_in=,
poll_out=, poll_err=0, event_thread_died=0 '\000') at
socket.c:2482
#12 0x00007f0ac23ed870 in event_dispatch_epoll_handler (event=0x7f0ab4a69e70,
event_pool=0x559b1ebc7250)
---Type to continue, or q to quit---
at event-epoll.c:643
#13 event_dispatch_epoll_worker (data=0x559b1ec250a0) at event-epoll.c:759
#14 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#15 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f0ab526b700 (LWP 4255)):
#0 0x00007f0ac11d14ed in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0ac11ccdcb in _L_lock_883 () from /lib64/libpthread.so.0
#2 0x00007f0ac11ccc98 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0ac23a1819 in inode_is_linked (inode=inode at entry=0x7f0a4c03b8f8) at
inode.c:2490
#4 0x00007f0aafdd2693 in afr_read_subvol_select_by_policy
(inode=inode at entry=0x7f0a4c03b8f8,
this=this at entry=0x7f097d715a70, readable=readable at entry=0x7f0ab526a420
"\001\001\001\265\n\177",
args=args at entry=0x0) at afr-common.c:1685
---Type to continue, or q to quit---
#5 0x00007f0aafdd29d6 in afr_read_subvol_get
(inode=inode at entry=0x7f0a4c03b8f8, this=0x7f097d715a70,
subvol_p=subvol_p at entry=0x0, readables=readables at entry=0x0,
event_p=event_p at entry=0x0,
type=type at entry=AFR_DATA_TRANSACTION, args=args at entry=0x0) at
afr-common.c:1771
#6 0x00007f0aafde1050 in afr_get_parent_read_subvol (readable=0x7f0ab526a540
"\001\001\001|\t\177",
replies=, parent=0x7f0a4c03b8f8, this=) at
afr-common.c:2167
#7 afr_lookup_done (frame=frame at entry=0x7f098664dcb8,
this=this at entry=0x7f097d715a70) at afr-common.c:2319
#8 0x00007f0aafde2058 in afr_lookup_metadata_heal_check
(frame=frame at entry=0x7f098664dcb8,
this=this at entry=0x7f097d715a70) at afr-common.c:2771
#9 0x00007f0aafde2a5b in afr_lookup_entry_heal
(frame=frame at entry=0x7f098664dcb8, this=this at entry=0x7f097d715a70)
at afr-common.c:2920
#10 0x00007f0aafde2e3d in afr_lookup_cbk (frame=frame at entry=0x7f098664dcb8,
cookie=,
this=0x7f097d715a70, op_ret=, op_errno=,
inode=inode at entry=0x7f09850f0d98,
buf=buf at entry=0x7f0ab526a900, xdata=0x7f0993075e88,
postparent=postparent at entry=0x7f0ab526a970)
---Type to continue, or q to quit---
at afr-common.c:2968
#11 0x00007f0ab4032efd in client3_3_lookup_cbk (req=,
iov=, count=,
myframe=0x7f0985df1b58) at client-rpc-fops.c:2872
#12 0x00007f0ac2134a00 in rpc_clnt_handle_reply
(clnt=clnt at entry=0x7f097c49ee60, pollin=pollin at entry=0x7f09937ef6c0)
at rpc-clnt.c:778
#13 0x00007f0ac2134d6b in rpc_clnt_notify (trans=,
mydata=0x7f097c49ee90, event=,
data=0x7f09937ef6c0) at rpc-clnt.c:971
#14 0x00007f0ac2130ae3 in rpc_transport_notify (this=this at entry=0x7f097e3ea6a0,
event=event at entry=RPC_TRANSPORT_MSG_RECEIVED,
data=data at entry=0x7f09937ef6c0) at rpc-transport.c:557
#15 0x00007f0ab6d22586 in socket_event_poll_in (this=this at entry=0x7f097e3ea6a0,
notify_handled=)
at socket.c:2322
#16 0x00007f0ab6d24bca in socket_event_handler (fd=29, idx=20, gen=7,
data=0x7f097e3ea6a0, poll_in=,
poll_out=, poll_err=0, event_thread_died=0 '\000') at
socket.c:2482
---Type to continue, or q to quit---
#17 0x00007f0ac23ed870 in event_dispatch_epoll_handler (event=0x7f0ab526ae70,
event_pool=0x559b1ebc7250)
at event-epoll.c:643
#18 event_dispatch_epoll_worker (data=0x559b1ec24dd0) at event-epoll.c:759
#19 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#20 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f0ab7735700 (LWP 4252)):
#0 0x00007f0ac11ced12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f0ac23cadd8 in syncenv_task (proc=proc at entry=0x559b1ebe3200) at
syncop.c:603
#2 0x00007f0ac23cbca0 in syncenv_processor (thdata=0x559b1ebe3200) at
syncop.c:695
#3 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
---Type to continue, or q to quit---
Thread 3 (Thread 0x7f0aacaad700 (LWP 4261)):
#0 0x00007f0ac11ce965 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f0ab97438d3 in notify_kernel_loop (data=) at
fuse-bridge.c:4584
#2 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f0ab8f38700 (LWP 4249)):
#0 0x00007f0ac11d2361 in sigwait () from /lib64/libpthread.so.0
#1 0x0000559b1de36c7b in glusterfs_sigwaiter (arg=) at
glusterfsd.c:2242
#2 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f0aadaaf700 (LWP 4259)):
---Type to continue, or q to quit---
#0 __dentry_search_arbit (inode=inode at entry=0x7f0a5002eab8) at inode.c:1450
#1 0x00007f0ac23a01c8 in __inode_path (inode=inode at entry=0x7f0a50009e68,
name=name at entry=0x7f0a028f1b50 "fresh_top.log",
bufp=bufp at entry=0x7f0985ba36e8)
at inode.c:1551
#2 0x00007f0ac23a0551 in inode_path (inode=0x7f0a50009e68,
name=0x7f0a028f1b50 "fresh_top.log", bufp=bufp at entry=0x7f0985ba36e8)
at inode.c:1642
#3 0x00007f0ab9740489 in fuse_resolve_entry (state=0x7f0985ba3570) at
fuse-resolve.c:99
#4 0x00007f0ab974162d in fuse_resolve_parent
(state=state at entry=0x7f0985ba3570) at fuse-resolve.c:312
#5 0x00007f0ab9741998 in fuse_resolve (state=0x7f0985ba3570) at
fuse-resolve.c:647
#6 0x00007f0ab9741c8e in fuse_resolve_all (state=) at
fuse-resolve.c:679
#7 0x00007f0ab9741cd0 in fuse_resolve_and_resume (state=0x7f0985ba3570,
fn=0x7f0ab9744e40 )
at fuse-resolve.c:718
---Type to continue, or q to quit---
#8 0x00007f0ab9759702 in fuse_thread_proc (data=0x559b1ebcf0c0) at
fuse-bridge.c:5781
#9 0x00007f0ac11cadd5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f0ac0a92ead in clone () from /lib64/libc.so.6
(gdb)
1. 3x3 volume
2. IOs triggered from 8 different clients both as root and non root user for
about a week, with quotas/uss enabled and set after 2 days
3. after about a week, did a add-brick with 3 replica sets to make it 6x3 and
triggered rebalance and left it over weekend
--- Additional comment from Amar Tumballi on 2019-03-04 11:49:51 UTC ---
Checking the core. My initial suspicion was on lru-limit, but doesn't look so.
---------------
(gdb) p name
$22 = 0x7f0a028f1b50 "fresh_top.log"
(gdb) p *inode
$23 = {table = 0x7f09971d46f0, gfid =
"\353\034\020'?G\266\271\034\240\031\205?L", lock = {spinlock = 0, mutex =
{__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0,
__list = {__prev = 0x0, __next = 0x0}}, __size = '\000' ,
__align = 0}}, nlookup = 0, fd_count = 0, active_fd_count = 0, ref = 3,
ia_type = IA_IFDIR, fd_list = {next = 0x7f0a50009ec0, prev = 0x7f0a50009ec0},
dentry_list = {next = 0x7f0a4c0386f8, prev = 0x7f0a4c0386f8}, hash = {next =
0x7f097f4971e0, prev = 0x7f097f4971e0}, list = {next = 0x7f0985631490,
prev = 0x7f098536bcf0}, _ctx = 0x7f0a50011380, invalidate_sent = _gf_false}
(gdb) p *inode->table
$24 = {lock = {__data = {__lock = 2, __count = 0, __owner = 4259, __nusers = 1,
__kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = "\002\000\000\000\000\000\000\000\243\020\000\000\001", '\000'
, __align = 2}, hashsize = 14057,
name = 0x7f098fc5b040 "meta-autoload/inode", root = 0x7f097ca5a168, xl =
0x7f097e043300, lru_limit = 131072, inode_hash = 0x7f097f414d20,
name_hash = 0x7f097f514d70, active = {next = 0x7f098536bcf0, prev =
0x7f097ca5a1f0}, active_size = 26, lru = {next = 0x7f0985f9ccd0, prev =
0x7f09803d4020},
lru_size = 70, purge = {next = 0x7f09971d4780, prev = 0x7f09971d4780},
purge_size = 0, inode_pool = 0x7f09971d4830, dentry_pool = 0x7f09971d48f0,
fd_mem_pool = 0x7f098df5eb80, ctxcount = 33, invalidator_fn = 0x7f0ab97425d0
, invalidator_xl = 0x559b1ebcf0c0, invalidate = {
next = 0x7f09971d47c8, prev = 0x7f09971d47c8}, invalidate_size = 0}
(gdb) p *inode->table->root
$29 = {table = 0x7f09971d46f0, gfid = '\000' , "\001", lock =
{spinlock = 0, mutex = {__data = {__lock = 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev
= 0x0, __next = 0x0}}, __size = '\000' , __align = 0}},
nlookup = 0, fd_count = 0, active_fd_count = 0, ref = 1, ia_type = IA_IFDIR,
fd_list = {next = 0x7f097ca5a1c0, prev = 0x7f097ca5a1c0}, dentry_list = {
next = 0x7f097ca5a1d0, prev = 0x7f097ca5a1d0}, hash = {next =
0x7f097f414d30, prev = 0x7f097f414d30}, list = {next = 0x7f09971d4750, prev =
0x7f0a50012840},
_ctx = 0x7f097c72e1a0, invalidate_sent = _gf_false}
(gdb) p *((dentry_t *)inode->dentry_list)
$26 = {inode_list = {next = 0x7f0a50009ed0, prev = 0x7f0a50009ed0}, hash =
{next = 0x7f097f536fc0, prev = 0x7f097f536fc0}, inode = 0x7f0a50009e68,
name = 0x7f0a4c00d340 "top.dir", parent = 0x7f0a5002eab8}
(gdb) p *((dentry_t *)inode->dentry_list)->parent
$27 = {table = 0x7f0a5004f6a8, gfid =
"\000\000\000\000\000\000\000\000\310\352\002P\n\177\000", lock = {spinlock =
1342368456, mutex = {__data = {
__lock = 1342368456, __count = 32522, __owner = 0, __nusers = 0, __kind
= 515698880, __spins = 21915, __elision = 0, __list = {__prev = 0x0,
__next = 0x0}}, __size =
"\310\352\002P\n\177\000\000\000\000\000\000\000\000\000\000\300\360\274\036\233U",
'\000' ,
__align = 139682268768968}}, nlookup = 0, fd_count = 0, active_fd_count =
0, ref = 4294967295, ia_type = IA_INVAL, fd_list = {next = 0x0, prev = 0x0},
dentry_list = {next = 0x0, prev = 0x100000000}, hash = {next = 0x0, prev =
0x0}, list = {next = 0x0, prev = 0x0}, _ctx = 0x0, invalidate_sent = _gf_false}
---------------
Notice that lru_size is no where close to lru-limit.
Also the inode by itself is fine. The issue is, while everything is under lock,
a parent dentry looks to be gone, or rather freed. A possible case of extra
unref() ??
Looking at the info, that this is 'top.dir' mostly it should have been linked
to root inode. But dentry is freed. Will look more into this, and keep this
updated. Also, looks like something which would have existed forever by the
first look.
--- Additional comment from Amar Tumballi on 2019-03-04 12:47:00 UTC ---
> [2019-03-01 13:37:02.711187] W [inode.c:197:__is_dentry_hashed] (-->/lib64/libglusterfs.so.0(__inode_path+0x68) [0x7f515a5cd1c8] -->/lib64/libglusterfs.so.0(+0x3add4) [0x7f515a5cadd4] -->/lib64/libglusterfs.so.0(+0x3ad7e) [0x7f515a5cad7e] ) 0-fuse: dentry not found
> pending frames:
> frame : type(1) op(UNLINK)
> frame : type(1) op(UNLINK)
> frame : type(1) op(READDIRP)
----
(gdb) bt
#0 __dentry_search_arbit (inode=inode at entry=0x7f0a5002eab8) at inode.c:1450
(gdb) l
1445 dentry_t *trav = NULL;
1446
1447 if (!inode)
1448 return NULL;
1449
1450 list_for_each_entry (trav, &inode->dentry_list, inode_list) {
1451 if (__is_dentry_hashed (trav)) {
1452 dentry = trav;
1453 break;
----
Looks like we need to see if trav is null, and break the loop. Mainly here,
__is_dentry_hashed() has given 0 output, and we still continue to traverse the
list. I guess, that should have stopped.
Still checking.
--- Additional comment from Amar Tumballi on 2019-03-04 14:23:18 UTC ---
As per comment #4,
> Also, looks like something which would have existed forever by the first look.
I suspect this to be a bug in code since a very long time. If in these lists,
if dentry is NULL, by the execution, next iteration will definitely crash,
which happened here. Need to traceback why this happened when every possible
change operation in inode happens with table lock.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685078
[Bug 1685078] systemic: gluster fuse crashed with segmentation fault possibly
due to dentry not found
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 14:37:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 14:37:45 +0000
Subject: [Bugs] [Bug 1686009] gluster fuse crashed with segmentation fault
possibly due to dentry not found
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686009
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22311
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 14:37:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 14:37:46 +0000
Subject: [Bugs] [Bug 1686009] gluster fuse crashed with segmentation fault
possibly due to dentry not found
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686009
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22311 (inode: check for instance of dentry
null) posted (#1) for review on master by Amar Tumballi
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:13:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:13:43 +0000
Subject: [Bugs] [Bug 1686034] New: Request access to docker hub gluster
organisation.
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686034
Bug ID: 1686034
Summary: Request access to docker hub gluster organisation.
Product: GlusterFS
Version: experimental
Status: NEW
Component: project-infrastructure
Severity: low
Assignee: bugs at gluster.org
Reporter: sseshasa at redhat.com
CC: bugs at gluster.org, gluster-infra at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
I request access to the docker hub gluster organisation in order to push and
manage docker images. My docker hub user ID is: sseshasa
I am not sure what to choose for "Product" and "Component" fields. Please
suggest/correct accordingly if they are wrong.
Version-Release number of selected component (if applicable):
NA
How reproducible:
NA
Steps to Reproduce:
1.
2.
3.
Actual results:
NA
Expected results:
NA
Additional info:
NA
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:18:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:18:23 +0000
Subject: [Bugs] [Bug 1686034] Request access to docker hub gluster
organisation.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686034
M. Scherer changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mscherer at redhat.com
--- Comment #1 from M. Scherer ---
So, what is the exact plan ? Shouldn't the docker image be built and pushed
automatically ?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:25:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:25:46 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On|1676468 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1676468
[Bug 1676468] glusterfs-fuse client not benefiting from page cache on read
after write
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:25:56 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:25:56 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On|1511779 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1511779
[Bug 1511779] Garbage collect inactive inodes in fuse-bridge
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:30:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:30:41 +0000
Subject: [Bugs] [Bug 1683880] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1683880
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |NEW
CC| |amukherj at redhat.com
--- Comment #2 from Atin Mukherjee ---
(In reply to Mohit Agrawal from comment #1)
> Upstream patch is posted to resolve the same
> https://review.gluster.org/#/c/glusterfs/+/22290/
this is an upstream bug only :-) Once the mainline patch is merged and we
backport it to release-6 branch, the bug status will be corrected.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:33:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:33:14 +0000
Subject: [Bugs] [Bug 1684404] Multiple shd processes are running on
brick_mux environmet
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amukherj at redhat.com
Blocks|1672818 (glusterfs-6.0) |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:33:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:33:14 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On|1684404 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684404
[Bug 1684404] Multiple shd processes are running on brick_mux environmet
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:33:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:33:44 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|1672818 (glusterfs-6.0) |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:33:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:33:44 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On|1685120 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
[Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:34:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:34:02 +0000
Subject: [Bugs] [Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1684029
Depends On|1684029 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1684029
[Bug 1684029] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:34:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:34:02 +0000
Subject: [Bugs] [Bug 1684029] upgrade from 3.12, 4.1 and 5 to 6 broken
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1684029
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|1685120 |
Depends On| |1685120
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1685120
[Bug 1685120] upgrade from 3.12, 4.1 and 5 to 6 broken
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:34:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:34:38 +0000
Subject: [Bugs] [Bug 1686034] Request access to docker hub gluster
organisation.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686034
--- Comment #2 from Sridhar Seshasayee ---
I have built a docker image locally and pushed it to my repository on docker
hub with user ID: sseshasa.
However, I need to push the same image under the gluster organisation on docker
hub (https://hub.docker.com/u/gluster) under gluster/gluster*. I don't know how
to achieve this and imagine that I need some access privilege to push images
there. Please let me know how I can go about this.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:35:16 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:35:16 +0000
Subject: [Bugs] [Bug 1679892] assertion failure log in glusterd.log file
when a volume start is triggered
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1679892
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|4.1 |6
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:37:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:37:05 +0000
Subject: [Bugs] [Bug 1664934] glusterfs-fuse client not benefiting from page
cache on read after write
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1664934
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amukherj at redhat.com
Blocks|1672818 (glusterfs-6.0) |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
[Bug 1672818] GlusterFS 6.0 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Wed Mar 6 15:37:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:37:05 +0000
Subject: [Bugs] [Bug 1672818] GlusterFS 6.0 tracker
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1672818
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On|1664934 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1664934
[Bug 1664934] glusterfs-fuse client not benefiting from page cache on read
after write
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 15:59:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 15:59:06 +0000
Subject: [Bugs] [Bug 1686034] Request access to docker hub gluster
organisation.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1686034
--- Comment #3 from M. Scherer ---
Nope, we do not allow direct push (or shouldn't). If you want a new image
there, you have to explain what it is, why it should be there, etc, etc. And
automate the push, for example, using a jenkins job. See for example this job:
https://build.gluster.org/job/glusterd2-containers/
http://git.gluster.org/cgit/build-jobs.git/tree/build-gluster-org/jobs/glusterd2-containers.yml
that's managed by gerrit, like the glusterfs source code.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
From bugzilla at redhat.com Wed Mar 6 18:40:39 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 06 Mar 2019 18:40:39 +0000
Subject: [Bugs] [Bug 1193929] GlusterFS can be improved
In-Reply-To: