From bugzilla at redhat.com Wed May 1 12:49:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 01 May 2019 12:49:15 +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 22652
--
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 May 1 12:49:16 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 01 May 2019 12:49:16 +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 #643 from Worker Ant ---
REVIEW: https://review.gluster.org/22652 (glusterd-utils.c: reduce work in
glusterd_add_volume_to_dict()) 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 Wed May 1 12:56:35 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 01 May 2019 12:56:35 +0000
Subject: [Bugs] [Bug 1697971] Segfault in FUSE process,
potential use after free
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1697971
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |atumball at redhat.com
--- Comment #19 from Amar Tumballi ---
Yes please, you can re-enable write-behind if you have upgraded to
glusterfs-5.5 or glusterfs-6.x releases.
--
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 May 1 12:57:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Wed, 01 May 2019 12:57:02 +0000
Subject: [Bugs] [Bug 1697971] Segfault in FUSE process,
potential use after free
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1697971
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |medium
--
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 Thu May 2 03:24:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 03:24:38 +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 #644 from Worker Ant ---
REVIEW: https://review.gluster.org/22580 (tests: Add changelog snapshot
testcase) 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 Thu May 2 04:01:29 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 04:01:29 +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
----------------------------------------------------------------------------
CC| |atumball at redhat.com
Flags| |needinfo?(atumball at redhat.c
| |om)
--- Comment #63 from Nithya Balachandran ---
(In reply to abhays from comment #60)
> Hi @Nithya,
>
> Any updates on this issue?
> Seems that the same test cases are failing in the Glusterfs v6.1 with
> additional ones:-
> ./tests/bugs/replicate/bug-1655854-support-dist-to-rep3-arb-conversion.t
> ./tests/features/fuse-lru-limit.t
>
> And one query we have with respect to these failures whether they affect the
> main functionality of Glusterfs or they can be ignored for now?
> Please let us know.
>
>
> Also, s390x systems have been added on the gluster-ci. Any updates regards
> to that?
I am no longer working on this. @Amar, please assign this to the appropriate
person.
--
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 Thu May 2 04:53:10 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 04:53:10 +0000
Subject: [Bugs] [Bug 1693692] Increase code coverage from regression tests
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1693692
--- Comment #33 from Worker Ant ---
REVIEW: https://review.gluster.org/22630 (tests: add .t files to increase cli
code coverage) merged (#3) 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 Thu May 2 06:00:52 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 06:00:52 +0000
Subject: [Bugs] [Bug 1693692] Increase code coverage from regression tests
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1693692
--- Comment #34 from Worker Ant ---
REVIEW: https://review.gluster.org/22631 (tests/cli: add .t file to increase
line coverage in cli) merged (#3) on master by Atin Mukherjee
--
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 Thu May 2 07:10:11 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 07:10:11 +0000
Subject: [Bugs] [Bug 1705351] New: glusterfsd crash after days of running
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705351
Bug ID: 1705351
Summary: glusterfsd crash after days of running
Product: GlusterFS
Version: mainline
Hardware: x86_64
OS: Linux
Status: NEW
Component: HDFS
Severity: urgent
Assignee: bugs at gluster.org
Reporter: waza123 at inbox.lv
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
One of brick just crashed glusterfsd and it cant be started again
What can I do to start it again ?
crash dump gdb:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 up_lk (frame=0x7fea88193f30, this=0x7feb3401c770, fd=0x0, cmd=6,
flock=0x7feb0d174d40, xdata=0x0) at upcall.c:239
239 local = upcall_local_init (frame, this, NULL, NULL, fd->inode, NULL);
[Current thread is 1 (Thread 0x7feb0031e700 (LWP 12319))]
(gdb) bt
#0 up_lk (frame=0x7fea88193f30, this=0x7feb3401c770, fd=0x0, cmd=6,
flock=0x7feb0d174d40, xdata=0x0) at upcall.c:239
#1 0x00007feb3e1cf65d in default_lk_resume (frame=0x7feb0d174ae0,
this=0x7feb3401e060, fd=0x0, cmd=6, lock=0x7feb0d174d40, xdata=0x0) at
defaults.c:1833
#2 0x00007feb3e166f35 in call_resume (stub=0x7feb0d174bf0) at call-stub.c:2508
#3 0x00007feb31e00d74 in iot_worker (data=0x7feb34058480) at io-threads.c:222
#4 0x00007feb3d8ca6ba in start_thread (arg=0x7feb0031e700) at
pthread_create.c:333
#5 0x00007feb3d60041d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) bt full
#0 up_lk (frame=0x7fea88193f30, this=0x7feb3401c770, fd=0x0, cmd=6,
flock=0x7feb0d174d40, xdata=0x0) at upcall.c:239
op_errno = -1
local = 0x0
__FUNCTION__ = "up_lk"
#1 0x00007feb3e1cf65d in default_lk_resume (frame=0x7feb0d174ae0,
this=0x7feb3401e060, fd=0x0, cmd=6, lock=0x7feb0d174d40, xdata=0x0) at
defaults.c:1833
_new = 0x7fea88193f30
old_THIS = 0x7feb3401e060
tmp_cbk = 0x7feb3e1bafa0
__FUNCTION__ = "default_lk_resume"
#2 0x00007feb3e166f35 in call_resume (stub=0x7feb0d174bf0) at call-stub.c:2508
old_THIS = 0x7feb3401e060
__FUNCTION__ = "call_resume"
#3 0x00007feb31e00d74 in iot_worker (data=0x7feb34058480) at io-threads.c:222
conf = 0x7feb34058480
this =
stub = 0x7feb0d174bf0
sleep_till = {tv_sec = 1556637893, tv_nsec = 0}
ret =
pri = 1
bye = _gf_false
__FUNCTION__ = "iot_worker"
#4 0x00007feb3d8ca6ba in start_thread (arg=0x7feb0031e700) at
pthread_create.c:333
__res =
pd = 0x7feb0031e700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140647297312512,
5756482990956014801, 0, 140648089937359, 140647297313216, 140648166818944,
-5749651260269466415,
-5749590536105693999}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0,
0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
pagesize_m1 =
sp =
freesize =
__PRETTY_FUNCTION__ = "start_thread"
#5 0x00007feb3d60041d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
(gdb)
# config
# gluster volume info
Volume Name: hadoop_volume
Type: Disperse
Volume ID: f13b43b0-ff9e-429b-81ed-15c92cdd1181
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: hdd1:/hadoop
Brick2: hdd2:/hadoop
Brick3: hdd3:/hadoop
Options Reconfigured:
cluster.disperse-self-heal-daemon: enable
server.statedump-path: /tmp
performance.client-io-threads: on
server.event-threads: 16
client.event-threads: 16
cluster.lookup-optimize: on
performance.parallel-readdir: on
transport.address-family: inet
nfs.disable: on
features.cache-invalidation: on
features.cache-invalidation-timeout: 600
performance.stat-prefetch: on
performance.cache-invalidation: on
performance.md-cache-timeout: 600
network.inode-lru-limit: 500000
features.lock-heal: on
# status
# gluster volume status
Status of volume: hadoop_volume
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick hdd1:/hadoop 49152 0 Y 5085
Brick hdd2:/hadoop 49152 0 Y 4044
Self-heal Daemon on localhost N/A N/A Y 2383
Self-heal Daemon on serv3 N/A N/A Y 2423
Self-heal Daemon on serv2 N/A N/A Y 3429
Self-heal Daemon on hdd2 N/A N/A Y 4035
Self-heal Daemon on hdd1 N/A N/A Y 5076
Task Status of Volume hadoop_volume
------------------------------------------------------------------------------
There are no active volume tasks
--
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 Thu May 2 12:13:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 12:13:45 +0000
Subject: [Bugs] [Bug 1705351] glusterfsd crash after days of running
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705351
Xavi Hernandez changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jahernan at redhat.com
--- Comment #1 from Xavi Hernandez ---
Can you upload the coredump to be able to analyze it ?
I will also need to know the exact version of gluster and the operating system
you are using.
To restart the crashed brick, the following command should help:
# gluster volume start hadoop_volume force
--
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 Thu May 2 12:16:21 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 12:16:21 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1616 from Worker Ant ---
REVIEW: https://review.gluster.org/22619 (glusterd: Fix coverity defects & put
coverity annotations) merged (#9) on master by Atin Mukherjee
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Thu May 2 17:10:34 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Thu, 02 May 2019 17:10:34 +0000
Subject: [Bugs] [Bug 1697971] Segfault in FUSE process,
potential use after free
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1697971
--- Comment #20 from Xavi Hernandez ---
>From my debugging I think the issue is related to a missing fd_ref() when
ob_open_behind() is used. This could potentially cause a race when the same fd
is being unref'ed (refcount becoming 0) and ref'ed at the same time to handle
some open_and_resume() requests. I have not yet identified the exact sequence
of operations that cause the problem though. Knowing that the problem really
comes from here, I'll investigate further.
--
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 May 3 04:37:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 04:37:03 +0000
Subject: [Bugs] [Bug 1705865] New: VM stuck in a shutdown because of a
pending fuse request
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705865
Bug ID: 1705865
Summary: VM stuck in a shutdown because of a pending fuse
request
Product: GlusterFS
Version: mainline
OS: Linux
Status: NEW
Component: write-behind
Severity: medium
Priority: medium
Assignee: bugs at gluster.org
Reporter: rgowdapp at redhat.com
CC: nravinas at redhat.com, rgowdapp at redhat.com,
rhinduja at redhat.com, rhs-bugs at redhat.com,
sankarshan at redhat.com
Depends On: 1702686
Target Milestone: ---
Group: redhat
Classification: Community
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Fri May 3 04:38:17 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 04:38:17 +0000
Subject: [Bugs] [Bug 1705865] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705865
Raghavendra G changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from Raghavendra G ---
VM fails to shutdown, getting stuck in 'Powering down' status. This is because
its 'qemu-kvm' process gets in a zombie/defunct state:
more ps-Ll.txt
F S UID PID PPID LWP C PRI NI ADDR SZ WCHAN TTY TIME CMD
6 Z 107 20631 1 20631 0 80 0 - 0 do_exi ? 8:45
[qemu-kvm]
3 D 107 20631 1 20635 0 80 0 - 2386845 fuse_r ? 1:12
[qemu-kvm]
The customer has collected a crash dump of the affected VM and also statedumps
from all the glusterfs process running in this machine when this problem is
present.
Thread ID 20635 is the one of interest:
crash> bt 20635
PID: 20635 TASK: ffff9ed3926eb0c0 CPU: 7 COMMAND: "IO iothread1"
#0 [ffff9ec8e351fa28] __schedule at ffffffff91967747
#1 [ffff9ec8e351fab0] schedule at ffffffff91967c49
#2 [ffff9ec8e351fac0] __fuse_request_send at ffffffffc09d24e5 [fuse]
#3 [ffff9ec8e351fb30] fuse_request_send at ffffffffc09d26e2 [fuse]
#4 [ffff9ec8e351fb40] fuse_send_write at ffffffffc09dbc76 [fuse]
#5 [ffff9ec8e351fb70] fuse_direct_io at ffffffffc09dc0d6 [fuse]
#6 [ffff9ec8e351fc58] __fuse_direct_write at ffffffffc09dc562 [fuse]
#7 [ffff9ec8e351fca8] fuse_direct_IO at ffffffffc09dd3ca [fuse]
#8 [ffff9ec8e351fd70] generic_file_direct_write at ffffffff913b8663
#9 [ffff9ec8e351fdc8] fuse_file_aio_write at ffffffffc09ddbd5 [fuse]
#10 [ffff9ec8e351fe60] do_io_submit at ffffffff91497a73
#11 [ffff9ec8e351ff40] sys_io_submit at ffffffff91497f40
#12 [ffff9ec8e351ff50] tracesys at ffffffff9197505b (via system_call)
RIP: 00007f9ff0758697 RSP: 00007f9db86814b8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: ffffffffffffffff
RDX: 00007f9db86814d0 RSI: 0000000000000001 RDI: 00007f9ff268e000
RBP: 0000000000000080 R8: 0000000000000080 R9: 000000000000006a
R10: 0000000000000078 R11: 0000000000000246 R12: 00007f9db86814c0
R13: 0000560264b9b518 R14: 0000560264b9b4f0 R15: 00007f9db8681bb0
ORIG_RAX: 00000000000000d1 CS: 0033 SS: 002b
>From the core, this is the file the above process is writing to:
crash> files -d 0xffff9ec8e8f9f740
DENTRY INODE SUPERBLK TYPE PATH
ffff9ec8e8f9f740 ffff9ed39e705700 ffff9ee009adc000 REG
/rhev/data-center/mnt/glusterSD/172.16.20.21:_vmstore2/e5dd645f-88bb-491c-9145-38fa229cbc4d/images/8e84c1ed-48ba-4b82-9882-c96e6f260bab/29bba0a1-6c7b-4358-9ef2-f8080405778d
So in this case we're accessing the vmstore2 volume.
This is the glusterfs process:
root 4863 0.0 0.0 1909580 49316 ? S bt 4863
PID: 4863 TASK: ffff9edfa9ff9040 CPU: 11 COMMAND: "glusterfs"
#0 [ffff9ed3a332fc28] __schedule at ffffffff91967747
#1 [ffff9ed3a332fcb0] schedule at ffffffff91967c49
#2 [ffff9ed3a332fcc0] futex_wait_queue_me at ffffffff9130cf76
#3 [ffff9ed3a332fd00] futex_wait at ffffffff9130dc5b
#4 [ffff9ed3a332fe48] do_futex at ffffffff9130f9a6
#5 [ffff9ed3a332fed8] sys_futex at ffffffff9130fec0
#6 [ffff9ed3a332ff50] system_call_fastpath at ffffffff91974ddb
RIP: 00007f6e5eeccf47 RSP: 00007ffdd311c7d0 RFLAGS: 00000246
RAX: 00000000000000ca RBX: 00007f6e59496700 RCX: ffffffffffffffff
RDX: 0000000000001308 RSI: 0000000000000000 RDI: 00007f6e594969d0
RBP: 00007f6e60552780 R8: 0000000000000000 R9: 00007f6e5e6e314d
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e59496d28
R13: 0000000000000000 R14: 0000000000000006 R15: 00007ffdd311c920
ORIG_RAX: 00000000000000ca CS: 0033 SS: 002b
We have a few pending frames in this process. Reviewing the corresponding
statedump:
grep complete=0 glusterdump.4863.dump.1556091368 -c
7
Looking for these pending frames in the statedump:
~~~
[global.callpool.stack.1]
stack=0x7f6e4007c828
uid=107
gid=107
pid=20635
unique=5518502
lk-owner=bd2351a6cc7fcb8b
op=WRITE
type=1
cnt=6
[global.callpool.stack.1.frame.1]
frame=0x7f6dec04de38
ref_count=0
translator=vmstore2-write-behind
complete=0
parent=vmstore2-open-behind
wind_from=default_writev_resume
wind_to=(this->children->xlator)->fops->writev
unwind_to=default_writev_cbk
[global.callpool.stack.1.frame.2]
frame=0x7f6dec0326f8
ref_count=1
translator=vmstore2-open-behind
complete=0
parent=vmstore2-md-cache
wind_from=mdc_writev
wind_to=(this->children->xlator)->fops->writev
unwind_to=mdc_writev_cbk
[global.callpool.stack.1.frame.3]
frame=0x7f6dec005bf8
ref_count=1
translator=vmstore2-md-cache
complete=0
parent=vmstore2-io-threads
wind_from=default_writev_resume
wind_to=(this->children->xlator)->fops->writev
unwind_to=default_writev_cbk
[global.callpool.stack.1.frame.4]
frame=0x7f6e400ab0f8
ref_count=1
translator=vmstore2-io-threads
complete=0
parent=vmstore2
wind_from=io_stats_writev
wind_to=(this->children->xlator)->fops->writev
unwind_to=io_stats_writev_cbk
[global.callpool.stack.1.frame.5]
frame=0x7f6e4007c6c8
ref_count=1
translator=vmstore2
complete=0
parent=fuse
wind_from=fuse_write_resume
wind_to=FIRST_CHILD(this)->fops->writev
unwind_to=fuse_writev_cbk
[global.callpool.stack.1.frame.6]
frame=0x7f6e4002cb98
ref_count=1
translator=fuse
complete=0
~~~
So I believe we're pending in the 'write-behind' translator. Please, I'd need
some help to figure out the cause of the hang.
Thank you,
Natalia
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Fri May 3 06:19:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 06:19:14 +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 #645 from Worker Ant ---
REVIEW: https://review.gluster.org/22652 (glusterd-utils.c: reduce work in
glusterd_add_volume_to_dict()) merged (#2) on master by Atin Mukherjee
--
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 May 3 06:44:21 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 06:44:21 +0000
Subject: [Bugs] [Bug 1705884] New: Image size as reported from the fuse
mount is incorrect
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705884
Bug ID: 1705884
Summary: Image size as reported from the fuse mount is
incorrect
Product: GlusterFS
Version: mainline
Hardware: x86_64
OS: Linux
Status: NEW
Component: sharding
Severity: high
Assignee: bugs at gluster.org
Reporter: kdhananj at redhat.com
QA Contact: bugs at gluster.org
CC: bugs at gluster.org, kdhananj at redhat.com, pasik at iki.fi,
rhs-bugs at redhat.com, sabose at redhat.com,
sankarshan at redhat.com, sasundar at redhat.com,
storage-qa-internal at redhat.com
Depends On: 1668001
Blocks: 1667998
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1668001 +++
Description of problem:
-----------------------
The size of the VM image file as reported from the fuse mount is incorrect.
For the file of size 1 TB, the size of the file on the disk is reported as 8
ZB.
Version-Release number of selected component (if applicable):
-------------------------------------------------------------
upstream master
How reproducible:
------------------
Always
Steps to Reproduce:
-------------------
1. On the Gluster storage domain, create the preallocated disk image of size
1TB
2. Check for the size of the file after its creation has succeesded
Actual results:
---------------
Size of the file is reported as 8 ZB, though the size of the file is 1TB
Expected results:
-----------------
Size of the file should be the same as the size created by the user
Additional info:
----------------
Volume in the question is replica 3 sharded
[root at rhsqa-grafton10 ~]# gluster volume info data
Volume Name: data
Type: Replicate
Volume ID: 7eb49e90-e2b6-4f8f-856e-7108212dbb72
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: rhsqa-grafton10.lab.eng.blr.redhat.com:/gluster_bricks/data/data
Brick2: rhsqa-grafton11.lab.eng.blr.redhat.com:/gluster_bricks/data/data
Brick3: rhsqa-grafton12.lab.eng.blr.redhat.com:/gluster_bricks/data/data
(arbiter)
Options Reconfigured:
performance.client-io-threads: on
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
cluster.choose-local: off
client.event-threads: 4
server.event-threads: 4
storage.owner-uid: 36
storage.owner-gid: 36
network.ping-timeout: 30
performance.strict-o-direct: on
cluster.granular-entry-heal: enable
cluster.enable-shared-storage: enable
--- Additional comment from SATHEESARAN on 2019-01-21 16:32:39 UTC ---
Size of the file as reported from the fuse mount:
[root@ ~]# ls -lsah
/rhev/data-center/mnt/glusterSD/rhsqa-grafton10.lab.eng.blr.redhat.com\:_data/bbeee86f-f174-4ec7-9ea3-a0df28709e64/images/0206953c-4850-4969-9dad-15140579d354/eaa5e81d-103c-4ce6-947e-8946806cca1b
8.0Z -rw-rw----. 1 vdsm kvm 1.1T Jan 21 17:14
/rhev/data-center/mnt/glusterSD/rhsqa-grafton10.lab.eng.blr.redhat.com:_data/bbeee86f-f174-4ec7-9ea3-a0df28709e64/images/0206953c-4850-4969-9dad-15140579d354/eaa5e81d-103c-4ce6-947e-8946806cca1b
[root@ ~]# du -shc
/rhev/data-center/mnt/glusterSD/rhsqa-grafton10.lab.eng.blr.redhat.com\:_data/bbeee86f-f174-4ec7-9ea3-a0df28709e64/images/0206953c-4850-4969-9dad-15140579d354/eaa5e81d-103c-4ce6-947e-8946806cca1b
16E
/rhev/data-center/mnt/glusterSD/rhsqa-grafton10.lab.eng.blr.redhat.com:_data/bbeee86f-f174-4ec7-9ea3-a0df28709e64/images/0206953c-4850-4969-9dad-15140579d354/eaa5e81d-103c-4ce6-947e-8946806cca1b
16E total
Note that the disk image is preallocated with 1072GB of space
--- Additional comment from SATHEESARAN on 2019-04-01 19:25:15 UTC ---
(In reply to SATHEESARAN from comment #5)
> (In reply to Krutika Dhananjay from comment #3)
> > Also, do you still have the setup in this state? If so, can I'd like to take
> > a look.
> >
> > -Krutika
>
> Hi Krutika,
>
> The setup is no longer available. Let me recreate the issue and provide you
> the setup
This issue is very easily reproducible. Create a preallocated image on the
replicate volume with sharding enabled.
Use 'qemu-img' to create the VM image.
See the following test:
[root@ ~]# qemu-img create -f raw -o preallocation=falloc /mnt/test/vm1.img 1T
Formatting '/mnt/test/vm1.img', fmt=raw size=1099511627776
preallocation='falloc'
[root@ ]# ls /mnt/test
vm1.img
[root@ ]# ls -lsah vm1.img
8.0Z -rw-r--r--. 1 root root 1.0T Apr 2 00:45 vm1.img
--- Additional comment from Krutika Dhananjay on 2019-04-11 06:07:35 UTC ---
So I tried this locally and I am not hitting the issue -
[root at dhcpxxxxx ~]# qemu-img create -f raw -o preallocation=falloc /mnt/vm1.img
10G
Formatting '/mnt/vm1.img', fmt=raw size=10737418240 preallocation=falloc
[root at dhcpxxxxx ~]# ls -lsah /mnt/vm1.img
10G -rw-r--r--. 1 root root 10G Apr 11 11:26 /mnt/vm1.img
[root at dhcpxxxxx ~]# qemu-img create -f raw -o preallocation=falloc /mnt/vm1.img
30G
Formatting '/mnt/vm1.img', fmt=raw size=32212254720 preallocation=falloc
[root at dhcpxxxxx ~]# ls -lsah /mnt/vm1.img
30G -rw-r--r--. 1 root root 30G Apr 11 11:32 /mnt/vm1.img
Of course, I didn't go beyond 30G due to space constraints on my laptop.
If you could share your setup where you're hitting this bug, I'll take a look.
-Krutika
--- Additional comment from SATHEESARAN on 2019-05-02 05:21:01 UTC ---
(In reply to Krutika Dhananjay from comment #7)
> So I tried this locally and I am not hitting the issue -
>
> [root at dhcpxxxxx ~]# qemu-img create -f raw -o preallocation=falloc
> /mnt/vm1.img 10G
> Formatting '/mnt/vm1.img', fmt=raw size=10737418240 preallocation=falloc
> [root at dhcpxxxxx ~]# ls -lsah /mnt/vm1.img
> 10G -rw-r--r--. 1 root root 10G Apr 11 11:26 /mnt/vm1.img
>
> [root at dhcpxxxxx ~]# qemu-img create -f raw -o preallocation=falloc
> /mnt/vm1.img 30G
> Formatting '/mnt/vm1.img', fmt=raw size=32212254720 preallocation=falloc
> [root at dhcpxxxxx ~]# ls -lsah /mnt/vm1.img
> 30G -rw-r--r--. 1 root root 30G Apr 11 11:32 /mnt/vm1.img
>
> Of course, I didn't go beyond 30G due to space constraints on my laptop.
>
> If you could share your setup where you're hitting this bug, I'll take a
> look.
>
> -Krutika
I could see this very consistenly in two fashions
1. Create VM image >= 1TB
--------------------------
[root at rhsqa-grafton7 test]# qemu-img create -f raw -o preallocation=falloc
vm1.img 10G
Formatting 'vm1.img', fmt=raw size=10737418240 preallocation=falloc
[root@ ]# ls -lsah vm1.img
10G -rw-r--r--. 1 root root 10G May 2 10:30 vm1.img
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm2.img 50G
Formatting 'vm2.img', fmt=raw size=53687091200 preallocation=falloc
[root@ ]# ls -lsah vm2.img
50G -rw-r--r--. 1 root root 50G May 2 10:30 vm2.img
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm3.img 100G
Formatting 'vm3.img', fmt=raw size=107374182400 preallocation=falloc
[root@ ]# ls -lsah vm3.img
100G -rw-r--r--. 1 root root 100G May 2 10:33 vm3.img
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm4.img 500G
Formatting 'vm4.img', fmt=raw size=536870912000 preallocation=falloc
[root@ ]# ls -lsah vm4.img
500G -rw-r--r--. 1 root root 500G May 2 10:33 vm4.img
Once the size reached 1TB, you will see this issue
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm6.img 1T
Formatting 'vm6.img', fmt=raw size=1099511627776 preallocation=falloc
[root@ ]# ls -lsah vm6.img
8.0Z -rw-r--r--. 1 root root 1.0T May 2 10:35 vm6.img <--------
size on disk is too much than expected
2. Recreate the image with the same name
-----------------------------------------
Observe that for the second time, the image is created with the same name
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm1.img 10G
Formatting 'vm1.img', fmt=raw size=10737418240 preallocation=falloc
[root@ ]# ls -lsah vm1.img
10G -rw-r--r--. 1 root root 10G May 2 10:40 vm1.img
[root@ ]# qemu-img create -f raw -o preallocation=falloc vm1.img 20G <--------
The same file name vm1.img is used
Formatting 'vm1.img', fmt=raw size=21474836480 preallocation=falloc
[root@ ]# ls -lsah vm1.img
30G -rw-r--r--. 1 root root 20G May 2 10:40 vm1.img <---------- size on
the disk is 30G, though the file is created with 20G
I will provide setup for the investigation
--- Additional comment from SATHEESARAN on 2019-05-02 05:23:07 UTC ---
The setup details:
-------------------
rhsqa-grafton7.lab.eng.blr.redhat.com ( root/redhat )
volume: data ( replica 3, sharded )
The volume is currently mounted at: /mnt/test
Note: This is the RHVH installation.
@krutika, if you need more info, just ping me in IRC / google chat
--- Additional comment from Krutika Dhananjay on 2019-05-02 10:16:40 UTC ---
Found part of the issue.
It's just a case of integer overflow.
32-bit signed int is being used to store delta between post-stat and pre-stat
block-counts.
The range of numbers for 32-bit signed int is [-2,147,483,648, 2,147,483,647]
whereas the number of blocks allocated
as part of creating a preallocated 1TB file is (1TB/512) = 2,147,483,648 which
is just 1 more than INT_MAX (2,147,483,647)
which spills over to the negative half the scale making it -2,147,483,648.
This number, on being copied to int64 causes the most-significant 32 bits to be
filled with 1 making the block-count equal 554050781183 (or 0xffffffff80000000)
in magnitude.
That's the block-count that gets set on the backend in
trusted.glusterfs.shard.file-size xattr in the block-count segment -
[root at rhsqa-grafton7 data]# getfattr -d -m . -e hex
/gluster_bricks/data/data/vm3.img
getfattr: Removing leading '/' from absolute path names
# file: gluster_bricks/data/data/vm3.img
security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.dirty=0x000000000000000000000000
trusted.gfid=0x3faffa7142b74e739f3a82b9359d33e6
trusted.gfid2path.6356251b968111ad=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f766d332e696d67
trusted.glusterfs.shard.block-size=0x0000000004000000
trusted.glusterfs.shard.file-size=0x00000100000000000000000000000000ffffffff800000000000000000000000
<-- notice the "ffffffff80000000" in the block-count segment
But ..
[root at rhsqa-grafton7 test]# stat vm3.img
File: ?vm3.img?
Size: 1099511627776 Blocks: 18446744071562067968 IO Block: 131072 regular
file
Device: 29h/41d Inode: 11473626732659815398 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:fusefs_t:s0
Access: 2019-05-02 14:11:11.693559069 +0530
Modify: 2019-05-02 14:12:38.245068328 +0530
Change: 2019-05-02 14:15:56.190546751 +0530
Birth: -
stat shows block-count as 18446744071562067968 which is way bigger than
(554050781183 * 512).
In the response path, turns out the block-count further gets assigned to a
uint64 number.
The same number, when expressed as uint64 becomes 18446744071562067968.
18446744071562067968 * 512 is a whopping 8.0 Zettabytes!
This bug wasn't seen earlier because the earlier way of preallocating files
never used fallocate, so the original signed 32 int variable delta_blocks would
never exceed 131072.
Anyway, I'll be soon sending a fix for this.
Sas,
Do you have a single node with at least 1TB free space that you can lend me
where I can test the fix? The bug will only be hit when the image size is >
1TB.
-Krutika
--- Additional comment from Krutika Dhananjay on 2019-05-02 10:18:26 UTC ---
(In reply to Krutika Dhananjay from comment #10)
> Found part of the issue.
Sorry, this not part of the issue but THE issue in its entirety. (That line is
from an older draft I'd composed which I forgot to change after rc'ing the bug)
>
> It's just a case of integer overflow.
> 32-bit signed int is being used to store delta between post-stat and
> pre-stat block-counts.
> The range of numbers for 32-bit signed int is [-2,147,483,648,
> 2,147,483,647] whereas the number of blocks allocated
> as part of creating a preallocated 1TB file is (1TB/512) = 2,147,483,648
> which is just 1 more than INT_MAX (2,147,483,647)
> which spills over to the negative half the scale making it -2,147,483,648.
> This number, on being copied to int64 causes the most-significant 32 bits to
> be filled with 1 making the block-count equal 554050781183 (or
> 0xffffffff80000000) in magnitude.
> That's the block-count that gets set on the backend in
> trusted.glusterfs.shard.file-size xattr in the block-count segment -
>
> [root at rhsqa-grafton7 data]# getfattr -d -m . -e hex
> /gluster_bricks/data/data/vm3.img
> getfattr: Removing leading '/' from absolute path names
> # file: gluster_bricks/data/data/vm3.img
> security.
> selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f7
> 43a733000
> trusted.afr.dirty=0x000000000000000000000000
> trusted.gfid=0x3faffa7142b74e739f3a82b9359d33e6
> trusted.gfid2path.
> 6356251b968111ad=0x30303030303030302d303030302d303030302d303030302d3030303030
> 303030303030312f766d332e696d67
>
> trusted.glusterfs.shard.block-size=0x0000000004000000
> trusted.glusterfs.shard.file-
> size=0x00000100000000000000000000000000ffffffff800000000000000000000000 <--
> notice the "ffffffff80000000" in the block-count segment
>
> But ..
>
> [root at rhsqa-grafton7 test]# stat vm3.img
> File: ?vm3.img?
> Size: 1099511627776 Blocks: 18446744071562067968 IO Block: 131072
> regular file
> Device: 29h/41d Inode: 11473626732659815398 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Context: system_u:object_r:fusefs_t:s0
> Access: 2019-05-02 14:11:11.693559069 +0530
> Modify: 2019-05-02 14:12:38.245068328 +0530
> Change: 2019-05-02 14:15:56.190546751 +0530
> Birth: -
>
> stat shows block-count as 18446744071562067968 which is way bigger than
> (554050781183 * 512).
>
> In the response path, turns out the block-count further gets assigned to a
> uint64 number.
> The same number, when expressed as uint64 becomes 18446744071562067968.
> 18446744071562067968 * 512 is a whopping 8.0 Zettabytes!
>
> This bug wasn't seen earlier because the earlier way of preallocating files
> never used fallocate, so the original signed 32 int variable delta_blocks
> would never exceed 131072.
>
> Anyway, I'll be soon sending a fix for this.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1667998
[Bug 1667998] Image size as reported from the fuse mount is incorrect
https://bugzilla.redhat.com/show_bug.cgi?id=1668001
[Bug 1668001] Image size as reported from the fuse mount is incorrect
--
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 May 3 06:56:33 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 06:56:33 +0000
Subject: [Bugs] [Bug 1654753] A distributed-disperse volume crashes when a
symbolic link is renamed
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1654753
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |high
CC| |atumball at redhat.com
Severity|unspecified |high
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Fri May 3 06:58:51 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 06:58:51 +0000
Subject: [Bugs] [Bug 1705884] Image size as reported from the fuse mount is
incorrect
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705884
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22655 (features/shard: Fix integer overflow
in block count accounting) posted (#1) for review on master by Krutika
Dhananjay
--
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 May 3 06:58:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 06:58:50 +0000
Subject: [Bugs] [Bug 1705884] Image size as reported from the fuse mount is
incorrect
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705884
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22655
--
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 May 3 07:23:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 07:23:12 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22656
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Fri May 3 07:23:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 07:23:13 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1617 from Worker Ant ---
REVIEW: https://review.gluster.org/22656 (glusterd: prevent use-after-free in
glusterd_op_ac_send_brick_op()) posted (#1) for review on master by Niels de
Vos
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Fri May 3 09:51:42 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 09:51:42 +0000
Subject: [Bugs] [Bug 1705351] glusterfsd crash after days of running
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705351
--- Comment #2 from waza123 at inbox.lv ---
https://drive.google.com/file/d/1n2IeRNqwXYmF1q664Rvtr5RuDu5taDz9/view?usp=sharing
--
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 May 3 12:06:55 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 12:06:55 +0000
Subject: [Bugs] [Bug 1705884] Image size as reported from the fuse mount is
incorrect
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705884
SATHEESARAN changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1668001
Depends On|1668001 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1668001
[Bug 1668001] Image size as reported from the fuse mount is incorrect
--
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 May 3 22:30:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Fri, 03 May 2019 22:30:15 +0000
Subject: [Bugs] [Bug 1690769] GlusterFS 5.5 crashes in 1x4 replicate setup.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1690769
--- Comment #4 from Artem Russakovskii ---
Phew, this was a fun one!
Long story short - after weeks of debugging with the amazing Gluster team
(thanks, Amar and Xavi!), we have found the root of the problem and a solution.
The crash happens on CPUs with an 'rtm' flag, in combination with slightly
older versions of glibc, specifically 2.26. The bug is fixed in glibc 2.29.
For example, 3 of our machines had these CPUs (run lscpu to find out):
Model name: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm
constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni
pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
xsave avx f16c rdrand hypervisor lahf_lm pti fsgsbase tsc_adjust smep erms
xsaveopt arat
And the one that was crashing had this one:
Model name: Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm
constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni
pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm
3dnowprefetch cpuid_fault invpcid_single pti fsgsbase tsc_adjust bmi1 hle avx2
smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
Since the version of glibc for OpenSUSE 15.0 is currently 2.26, the easiest
solution was to migrate the box to a CPU without the rtm feature, which we've
now done and confirmed the crash is gone.
Before the migration, Xavi did find a workaround:
1. export GLIBC_TUNABLES=glibc.tune.hwcaps=-RTM
2. Unmount and remount.
3. Confirm the above worked: for i in $(pgrep glusterfs); do ps h -o cmd -p $i;
cat /proc/$i/environ | xargs -0 -n 1 | grep "GLIBC_TUNABLES"; done
More info about this lock elision feature, as well as a quick test program can
be found here: https://sourceware.org/bugzilla/show_bug.cgi?id=23275.
Here are sample runs on hardware with 'rtm' feature (crash observed) and
without (no crash):
gcc -pthread test.c -o test
archon810 at citadel:/tmp> ./test
Please add a check if lock-elision is available on your architecture. The check
in check_if_lock_elision_is_available () assumes, that lock-elision is enabled!
main: start 3 threads to run 2000000 iterations.
#0: started
#1: started
#2: started
.#0: pthread_mutex_destroy: failed with 16; in round=2295;
Aborted
archon810 at hive:/tmp> ./test
Please add a check if lock-elision is available on your architecture. The check
in check_if_lock_elision_is_available () assumes, that lock-elision is enabled!
main: start 3 threads to run 2000000 iterations.
#0: started
#2: started
#1: started
........................................................................................................................................................................................................main:
end.
Not sure how the maintainers will choose to close this issue, but I hope it'll
help someone in the future, especially since we spent countless hours analyzing
and debugging (hopefully, not all in vain!).
--
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 May 4 07:23:48 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 04 May 2019 07:23:48 +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 22659
--
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 May 4 07:23:49 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sat, 04 May 2019 07:23:49 +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 #646 from Worker Ant ---
REVIEW: https://review.gluster.org/22659 ([WIP]glusterd-utils.c: reduce some
work) 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 May 5 15:52:18 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 05 May 2019 15:52:18 +0000
Subject: [Bugs] [Bug 1706603] New: Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Bug ID: 1706603
Summary: Glusterfsd crashing in ec-inode-write.c, in GF_ASSERT
Product: GlusterFS
Version: mainline
Status: NEW
Component: disperse
Assignee: bugs at gluster.org
Reporter: pkarampu at redhat.com
Target Milestone: ---
Group: private
Classification: Community
Mount crashing in an 'ASSERT' that checks the inode size in the function
ec-inode-write.c
Program terminated with signal 11, Segmentation fault.
#0 0x00007f5502715dcb in ec_manager_truncate (fop=0x7f53ff654910,
state=) at ec-inode-write.c:1475
1475 GF_ASSERT(ec_get_inode_size(fop,
fop->locks[0].lock->loc.inode,
This is the corresponding thread:
Thread 1 (Thread 0x7f54f907a700 (LWP 31806)):
#0 0x00007f5502715dcb in ec_manager_truncate (fop=0x7f53ff654910,
state=) at ec-inode-write.c:1475
#1 0x00007f55026f399b in __ec_manager (fop=0x7f53ff654910, error=0) at
ec-common.c:2698
#2 0x00007f55026f3b78 in ec_resume (fop=0x7f53ff654910, error=0) at
ec-common.c:481
#3 0x00007f55026f3c9f in ec_complete (fop=0x7f53ff654910) at ec-common.c:554
#4 0x00007f5502711d0c in ec_inode_write_cbk (frame=,
this=0x7f54fc186380, cookie=0x3, op_ret=0, op_errno=0, prestat=0x7f54f9079920,
poststat=0x7f54f9079990, xdata=0x0) at ec-inode-write.c:156
#5 0x00007f550298224c in client3_3_ftruncate_cbk (req=,
iov=, count=, myframe=0x7f5488ba7870) at
client-rpc-fops.c:1415
#6 0x00007f5510476960 in rpc_clnt_handle_reply
(clnt=clnt at entry=0x7f54fc4a1330, pollin=pollin at entry=0x7f549b65dc30) at
rpc-clnt.c:778
#7 0x00007f5510476d03 in rpc_clnt_notify (trans=,
mydata=0x7f54fc4a1360, event=, data=0x7f549b65dc30) at
rpc-clnt.c:971
#8 0x00007f5510472a73 in rpc_transport_notify (this=this at entry=0x7f54fc4a1500,
event=event at entry=RPC_TRANSPORT_MSG_RECEIVED, data=data at entry=0x7f549b65dc30)
at rpc-transport.c:538
#9 0x00007f5505067566 in socket_event_poll_in (this=this at entry=0x7f54fc4a1500,
notify_handled=) at socket.c:2315
#10 0x00007f5505069b0c in socket_event_handler (fd=90, idx=99, gen=472,
data=0x7f54fc4a1500, poll_in=1, poll_out=0, poll_err=0) at socket.c:2467
#11 0x00007f551070c7e4 in event_dispatch_epoll_handler (event=0x7f54f9079e80,
event_pool=0x5625cf18aa30) at event-epoll.c:583
#12 event_dispatch_epoll_worker (data=0x7f54fc296580) at event-epoll.c:659
#13 0x00007f550f50ddd5 in start_thread (arg=0x7f54f907a700) at
pthread_create.c:307
#14 0x00007f550edd5ead in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
We're crashing in this part of the code, specifically:
(gdb) l
1470
1471 /* This shouldn't fail because we have the inode
locked. */
1472 /* Inode size doesn't need to be updated under locks,
because
1473 * conflicting operations won't be in-flight
1474 */
1475 GF_ASSERT(ec_get_inode_size(fop,
fop->locks[0].lock->loc.inode,
1476 &cbk->iatt[0].ia_size));
1477 cbk->iatt[1].ia_size = fop->user_size;
1478 /* This shouldn't fail because we have the inode
locked. */
1479 GF_ASSERT(ec_set_inode_size(fop,
fop->locks[0].lock->loc.inode,
(gdb) p *cbk
$7 = {list = {next = 0x7f53ff654950, prev = 0x7f53ff654950}, answer_list =
{next = 0x7f53ff654960, prev = 0x7f53ff654960}, fop = 0x7f53ff654910, next =
0x0, idx = 3, op_ret = 0, op_errno = 0, count = 1, mask = 8,
xdata = 0x0, dict = 0x0, int32 = 0, uintptr = {0, 0, 0}, size = 0, version =
{0, 0}, inode = 0x0, fd = 0x0, statvfs = {f_bsize = 0, f_frsize = 0, f_blocks =
0, f_bfree = 0, f_bavail = 0, f_files = 0, f_ffree = 0,
f_favail = 0, f_fsid = 0, f_flag = 0, f_namemax = 0, __f_spare = {0, 0, 0,
0, 0, 0}}, iatt = {{ia_ino = 12285952560967103824, ia_gfid =
"\337\b\247-\b\344F?\200x?\276\265P", ia_dev = 2224, ia_type = IA_IFREG,
ia_prot = {suid = 0 '\000', sgid = 0 '\000', sticky = 0 '\000', owner =
{read = 1 '\001', write = 1 '\001', exec = 1 '\001'}, group = {read = 1 '\001',
write = 0 '\000', exec = 1 '\001'}, other = {read = 1 '\001',
write = 0 '\000', exec = 1 '\001'}}, ia_nlink = 1, ia_uid = 0, ia_gid
= 0, ia_rdev = 0, ia_size = 491520, ia_blksize = 4096, ia_blocks = 3840,
ia_atime = 1557032019, ia_atime_nsec = 590833985,
ia_mtime = 1557032498, ia_mtime_nsec = 824769499, ia_ctime = 1557032498,
ia_ctime_nsec = 824769499}, {ia_ino = 12285952560967103824, ia_gfid =
"\337\b\247-\b\344F?\200x?\276\265P", ia_dev = 2224, ia_type = IA_IFREG,
ia_prot = {suid = 0 '\000', sgid = 0 '\000', sticky = 0 '\000', owner =
{read = 1 '\001', write = 1 '\001', exec = 1 '\001'}, group = {read = 1 '\001',
write = 0 '\000', exec = 1 '\001'}, other = {read = 1 '\001',
write = 0 '\000', exec = 1 '\001'}}, ia_nlink = 1, ia_uid = 0, ia_gid
= 0, ia_rdev = 0, ia_size = 0, ia_blksize = 4096, ia_blocks = 0, ia_atime =
1557032019, ia_atime_nsec = 590833985, ia_mtime = 1557032498,
ia_mtime_nsec = 824769499, ia_ctime = 1557032498, ia_ctime_nsec =
824769499}, {ia_ino = 0, ia_gfid = '\000' , ia_dev = 0,
ia_type = IA_INVAL, ia_prot = {suid = 0 '\000', sgid = 0 '\000',
sticky = 0 '\000', owner = {read = 0 '\000', write = 0 '\000', exec = 0
'\000'}, group = {read = 0 '\000', write = 0 '\000', exec = 0 '\000'}, other =
{read = 0 '\000', write = 0 '\000', exec = 0 '\000'}},
ia_nlink = 0, ia_uid = 0, ia_gid = 0, ia_rdev = 0, ia_size = 0,
ia_blksize = 0, ia_blocks = 0, ia_atime = 0, ia_atime_nsec = 0, ia_mtime = 0,
ia_mtime_nsec = 0, ia_ctime = 0, ia_ctime_nsec = 0}, {ia_ino = 0,
ia_gfid = '\000' , ia_dev = 0, ia_type = IA_INVAL,
ia_prot = {suid = 0 '\000', sgid = 0 '\000', sticky = 0 '\000', owner = {read =
0 '\000', write = 0 '\000', exec = 0 '\000'}, group = {
read = 0 '\000', write = 0 '\000', exec = 0 '\000'}, other = {read =
0 '\000', write = 0 '\000', exec = 0 '\000'}}, ia_nlink = 0, ia_uid = 0, ia_gid
= 0, ia_rdev = 0, ia_size = 0, ia_blksize = 0, ia_blocks = 0,
ia_atime = 0, ia_atime_nsec = 0, ia_mtime = 0, ia_mtime_nsec = 0,
ia_ctime = 0, ia_ctime_nsec = 0}, {ia_ino = 0, ia_gfid = '\000' , ia_dev = 0, ia_type = IA_INVAL, ia_prot = {suid = 0 '\000',
sgid = 0 '\000', sticky = 0 '\000', owner = {read = 0 '\000', write = 0
'\000', exec = 0 '\000'}, group = {read = 0 '\000', write = 0 '\000', exec = 0
'\000'}, other = {read = 0 '\000', write = 0 '\000',
exec = 0 '\000'}}, ia_nlink = 0, ia_uid = 0, ia_gid = 0, ia_rdev = 0,
ia_size = 0, ia_blksize = 0, ia_blocks = 0, ia_atime = 0, ia_atime_nsec = 0,
ia_mtime = 0, ia_mtime_nsec = 0, ia_ctime = 0, ia_ctime_nsec = 0}},
flock = {l_type = 0, l_whence = 0, l_start = 0, l_len = 0, l_pid = 0, l_owner
= {len = 0, data = '\000' }}, vector = 0x0, buffers = 0x0,
str = 0x0, entries = {{list = {next = 0x7f54429a3188,
prev = 0x7f54429a3188}, {next = 0x7f54429a3188, prev =
0x7f54429a3188}}, d_ino = 0, d_off = 0, d_len = 0, d_type = 0, d_stat = {ia_ino
= 0, ia_gfid = '\000' , ia_dev = 0, ia_type = IA_INVAL,
ia_prot = {suid = 0 '\000', sgid = 0 '\000', sticky = 0 '\000', owner =
{read = 0 '\000', write = 0 '\000', exec = 0 '\000'}, group = {read = 0 '\000',
write = 0 '\000', exec = 0 '\000'}, other = {read = 0 '\000',
write = 0 '\000', exec = 0 '\000'}}, ia_nlink = 0, ia_uid = 0, ia_gid
= 0, ia_rdev = 0, ia_size = 0, ia_blksize = 0, ia_blocks = 0, ia_atime = 0,
ia_atime_nsec = 0, ia_mtime = 0, ia_mtime_nsec = 0, ia_ctime = 0,
ia_ctime_nsec = 0}, dict = 0x0, inode = 0x0, d_name = 0x7f54429a3230 ""},
offset = 0, what = GF_SEEK_DATA}
(gdb) p *cbk->fop
$8 = {id = 24, refs = 3, state = 4, minimum = 1, expected = 1, winds = 0, jobs
= 1, error = 0, parent = 0x7f532c197d80, xl = 0x7f54fc186380, req_frame =
0x7f532c048c60, frame = 0x7f54700662d0, cbk_list = {
next = 0x7f54429a2a10, prev = 0x7f54429a2a10}, answer_list = {next =
0x7f54429a2a20, prev = 0x7f54429a2a20}, pending_list = {next = 0x7f533007acc0,
prev = 0x7f5477976ac0}, answer = 0x7f54429a2a10, lock_count = 0,
locked = 0, locks = {{lock = 0x0, fop = 0x0, owner_list = {next =
0x7f53ff6549a0, prev = 0x7f53ff6549a0}, wait_list = {next = 0x7f53ff6549b0,
prev = 0x7f53ff6549b0}, update = {_gf_false, _gf_false}, dirty = {_gf_false,
_gf_false}, optimistic_changelog = _gf_false, base = 0x0, size = 0,
waiting_flags = 0, fl_start = 0, fl_end = 0}, {lock = 0x0, fop = 0x0,
owner_list = {next = 0x7f53ff654a10, prev = 0x7f53ff654a10}, wait_list = {
next = 0x7f53ff654a20, prev = 0x7f53ff654a20}, update = {_gf_false,
_gf_false}, dirty = {_gf_false, _gf_false}, optimistic_changelog = _gf_false,
base = 0x0, size = 0, waiting_flags = 0, fl_start = 0, fl_end = 0}},
first_lock = 0, 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}}, flags = 0, first = 0,
mask = 8, healing = 0, remaining = 0, received = 8, good = 8, uid = 0, gid = 0,
wind = 0x7f5502710ae0 ,
handler = 0x7f5502715c50 , resume = 0x0, cbks = {access
= 0x7f550270af50 , create = 0x7f550270af50
, discard = 0x7f550270af50 ,
entrylk = 0x7f550270af50 , fentrylk = 0x7f550270af50
, fallocate = 0x7f550270af50 ,
flush = 0x7f550270af50 ,
fsync = 0x7f550270af50 , fsyncdir = 0x7f550270af50
, getxattr = 0x7f550270af50 ,
fgetxattr = 0x7f550270af50 ,
heal = 0x7f550270af50 , fheal = 0x7f550270af50
, inodelk = 0x7f550270af50 ,
finodelk = 0x7f550270af50 ,
link = 0x7f550270af50 , lk = 0x7f550270af50
, lookup = 0x7f550270af50 , mkdir =
0x7f550270af50 ,
mknod = 0x7f550270af50 , open = 0x7f550270af50
, opendir = 0x7f550270af50 ,
readdir = 0x7f550270af50 ,
readdirp = 0x7f550270af50 , readlink = 0x7f550270af50
, readv = 0x7f550270af50 ,
removexattr = 0x7f550270af50 ,
fremovexattr = 0x7f550270af50 , rename =
0x7f550270af50 , rmdir = 0x7f550270af50
, setattr = 0x7f550270af50 ,
fsetattr = 0x7f550270af50 , setxattr = 0x7f550270af50
, fsetxattr = 0x7f550270af50 , stat
= 0x7f550270af50 ,
fstat = 0x7f550270af50 , statfs = 0x7f550270af50
, symlink = 0x7f550270af50 ,
truncate = 0x7f550270af50 ,
ftruncate = 0x7f550270af50 , unlink = 0x7f550270af50
, writev = 0x7f550270af50 , xattrop
= 0x7f550270af50 ,
fxattrop = 0x7f550270af50 , zerofill = 0x7f550270af50
, seek = 0x7f550270af50 , ipc =
0x7f550270af50 }, data = 0x7f5477976a60,
heal = 0x0, healer = {next = 0x7f53ff654b08, prev = 0x7f53ff654b08},
user_size = 0, head = 0, use_fd = 1, xdata = 0x0, dict = 0x0, int32 = 0, uint32
= 0, size = 0, offset = 0, mode = {0, 0}, entrylk_cmd = ENTRYLK_LOCK,
entrylk_type = ENTRYLK_RDLCK, xattrop_flags = GF_XATTROP_ADD_ARRAY, dev = 0,
inode = 0x0, fd = 0x7f54dfb900a0, iatt = {ia_ino = 0, ia_gfid = '\000' , ia_dev = 0, ia_type = IA_INVAL, ia_prot = {
suid = 0 '\000', sgid = 0 '\000', sticky = 0 '\000', owner = {read = 0
'\000', write = 0 '\000', exec = 0 '\000'}, group = {read = 0 '\000', write = 0
'\000', exec = 0 '\000'}, other = {read = 0 '\000',
write = 0 '\000', exec = 0 '\000'}}, ia_nlink = 0, ia_uid = 0, ia_gid =
0, ia_rdev = 0, ia_size = 0, ia_blksize = 0, ia_blocks = 0, ia_atime = 0,
ia_atime_nsec = 0, ia_mtime = 0, ia_mtime_nsec = 0, ia_ctime = 0,
ia_ctime_nsec = 0}, str = {0x0, 0x0}, loc = {{path = 0x0, name = 0x0, inode
= 0x0, parent = 0x0, gfid = '\000' , pargfid = '\000'
}, {path = 0x0, name = 0x0, inode = 0x0, parent = 0x0,
gfid = '\000' , pargfid = '\000' }},
flock = {l_type = 0, l_whence = 0, l_start = 0, l_len = 0, l_pid = 0, l_owner =
{len = 0, data = '\000' }}, vector = 0x0,
buffers = 0x0, seek = GF_SEEK_DATA, errstr = 0x0}
Checking further the lock:
(gdb) p fop->locks[0]
$5 = {lock = 0x0, fop = 0x0, owner_list = {next = 0x7f53ff6549a0, prev =
0x7f53ff6549a0}, wait_list = {next = 0x7f53ff6549b0, prev = 0x7f53ff6549b0},
update = {_gf_false, _gf_false}, dirty = {_gf_false, _gf_false},
optimistic_changelog = _gf_false, base = 0x0, size = 0, waiting_flags = 0,
fl_start = 0, fl_end = 0}
(gdb) p fop->locks[0].lock
$6 = (ec_lock_t *) 0x0
(gdb) p fop->locks[0].lock->loc.inode
Cannot access memory at address 0x90
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Sun May 5 17:02:56 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Sun, 05 May 2019 17:02:56 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Pranith Kumar K changed:
What |Removed |Added
----------------------------------------------------------------------------
Group|private |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 00:01:56 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 00:01:56 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22660
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 00:01:57 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 00:01:57 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-05-06 00:01:57
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22660 (cluster/ec: Reopen shouldn't happen
with O_TRUNC) merged (#1) on master by Pranith Kumar Karampuri
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 04:08:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 04:08:46 +0000
Subject: [Bugs] [Bug 1706683] New: Enable enable fips-mode-rchecksum for new
volumes by default
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
Bug ID: 1706683
Summary: Enable enable fips-mode-rchecksum for new volumes by
default
Product: Red Hat Gluster Storage
Version: rhgs-3.5
Status: NEW
Component: glusterd
Keywords: Triaged
Assignee: amukherj at redhat.com
Reporter: ravishankar at redhat.com
QA Contact: bmekala at redhat.com
CC: bugs at gluster.org, rhs-bugs at redhat.com,
sankarshan at redhat.com, storage-qa-internal at redhat.com,
vbellur at redhat.com
Depends On: 1702303
Target Milestone: ---
Classification: Red Hat
+++ This bug was initially created as a clone of Bug #1702303 +++
Description of problem:
fips-mode-rchecksum option was provided in GD_OP_VERSION_4_0_0 to maintain
backward compatibility with older AFR so that a cluster operating at an op
version of less than GD_OP_VERSION_4_0_0 used MD5SUM instead of the SHA256 that
would be used if this option was enabled.
But in a freshly created setup with cluster op-version >=GD_OP_VERSION_4_0_0,
we can directly go ahead and use SHA256 without asking the admin to explicitly
set the volume option 'on'.
In fact in downstream, this created quite a bit of confusion when QE would
created a new glusterfs setup on a FIPS enabled machine and would try out
self-heal test cases (without setting 'fips-mode-rchecksum' on), leading to
crashes due to non-compliance. Ideally this fix should have been done as a part
of the original commit: "6daa65356 - posix/afr: handle backward compatibility
for rchecksum fop" but I guess it is better late than never.
--- Additional comment from Worker Ant on 2019-04-26 08:23:27 UTC ---
REVIEW: https://review.gluster.org/22609 (glusterd: enable fips-mode-rchecksum
for new volumes) merged (#4) on master by Atin Mukherjee
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1702303
[Bug 1702303] Enable enable fips-mode-rchecksum for new volumes by default
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 04:08:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 04:08:46 +0000
Subject: [Bugs] [Bug 1702303] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1702303
Ravishankar N changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1706683
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
[Bug 1706683] Enable enable fips-mode-rchecksum for new volumes by default
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 04:08:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 04:08:50 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
RHEL Product and Program Management changed:
What |Removed |Added
----------------------------------------------------------------------------
Rule Engine Rule| |Gluster: set proposed
| |release flag for new BZs at
| |RHGS
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 04:10:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 04:10:05 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
--- Comment #2 from Ravishankar N ---
Note: In upstream, the fix was tied to GD_OP_VERSION_7_0. We might need to use
the right op-version in the downstream backport.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 04:10:38 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 04:10:38 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
Ravishankar N changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|amukherj at redhat.com |ravishankar at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 05:18:30 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 05:18:30 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22661
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 05:18:30 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 05:18:30 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1618 from Worker Ant ---
REVIEW: https://review.gluster.org/22661 (glusterd: coverity fix) posted (#1)
for review on master by Atin Mukherjee
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 07:00:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:00:44 +0000
Subject: [Bugs] [Bug 1214644] Upcall: Migrate state during rebalance/tiering
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1214644
Soumya Koduri changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |WONTFIX
Flags|needinfo?(skoduri at redhat.co |
|m) |
Last Closed| |2019-05-06 07:00:44
--- Comment #4 from Soumya Koduri ---
This is a Day1 issue (i.e, rebalance and self-healing does not happen for most
of the state maintained at the server-side) and there are no plans to address
it in the near future. Hence closing the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 07:01:09 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:01:09 +0000
Subject: [Bugs] [Bug 1706716] New: glusterd generated core while running
./tests/bugs/cli/bug-1077682.t
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706716
Bug ID: 1706716
Summary: glusterd generated core while running
./tests/bugs/cli/bug-1077682.t
Product: GlusterFS
Version: mainline
Status: NEW
Component: glusterd
Assignee: bugs at gluster.org
Reporter: srakonde at redhat.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
glusterd generated a core file while running ./tests/bugs/cli/bug-1077682.t in
centos running. Core and logs can be found in
https://build.gluster.org/job/centos7-regression/5857/consoleFull
--
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 May 6 07:01:16 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:01:16 +0000
Subject: [Bugs] [Bug 1214654] Self-heal: Migrate lease_locks as part of
self-heal process
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1214654
Soumya Koduri changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |WONTFIX
Flags|needinfo?(skoduri at redhat.co |
|m) |
Last Closed| |2019-05-06 07:01:16
--- Comment #2 from Soumya Koduri ---
This is a Day1 issue (i.e, rebalance and self-healing does not happen for most
of the state maintained at the server-side) and there are no plans to address
it in the near future. Hence closing the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 07:02:54 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:02:54 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
Ravishankar N changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
--- Comment #3 from Ravishankar N ---
(In reply to Ravishankar N from comment #2)
> Note: In upstream, the fix was tied to GD_OP_VERSION_7_0. We might need to
> use the right op-version in the downstream backport.
rhgs-3.5.0 also uses GD_OP_VERSION_7_0 for the maximum op-version, so the patch
is a straight forward back-port:
https://code.engineering.redhat.com/gerrit/#/c/169443/
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 07:02:14 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:02:14 +0000
Subject: [Bugs] [Bug 1706716] glusterd generated core while running
./tests/bugs/cli/bug-1077682.t
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706716
Sanju changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs at gluster.org |srakonde at redhat.com
--- Comment #1 from Sanju ---
s/"centos running"/"centos regression"
--
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 May 6 07:07:21 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 07:07:21 +0000
Subject: [Bugs] [Bug 1705351] glusterfsd crash after days of running
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705351
--- Comment #3 from Xavi Hernandez ---
Thanks for the sharing the coredump. I'll take a look as soon as I can.
--
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 May 6 09:41:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 09:41:15 +0000
Subject: [Bugs] [Bug 1693692] Increase code coverage from regression tests
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1693692
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22664
--
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 May 6 09:41:16 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 09:41:16 +0000
Subject: [Bugs] [Bug 1693692] Increase code coverage from regression tests
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1693692
--- Comment #35 from Worker Ant ---
REVIEW: https://review.gluster.org/22664 (glusterd/tier: remove tier related
code from glusterd) posted (#1) for review on master by hari gowtham
--
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 May 6 09:49:59 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 09:49:59 +0000
Subject: [Bugs] [Bug 1706716] glusterd generated core while running
./tests/bugs/cli/bug-1077682.t
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706716
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amukherj at redhat.com
--- Comment #2 from Atin Mukherjee ---
(gdb) bt
#0 0x00007fa56532b207 in raise () from ./lib64/libc.so.6
#1 0x00007fa56532c8f8 in abort () from ./lib64/libc.so.6
#2 0x00007fa56536dd27 in __libc_message () from ./lib64/libc.so.6
#3 0x00007fa56536de0e in __libc_fatal () from ./lib64/libc.so.6
#4 0x00007fa56536e183 in _IO_vtable_check () from ./lib64/libc.so.6
#5 0x00007fa565372c9b in _IO_cleanup () from ./lib64/libc.so.6
#6 0x00007fa56532eb1b in __run_exit_handlers () from ./lib64/libc.so.6
#7 0x00007fa56532ebb7 in exit () from ./lib64/libc.so.6
#8 0x0000000000409485 in cleanup_and_exit (signum=15) at
/home/jenkins/root/workspace/centos7-regression/glusterfsd/src/glusterfsd.c:1659
#9 0x000000000040b093 in glusterfs_sigwaiter (arg=0x7fff6cf56250) at
/home/jenkins/root/workspace/centos7-regression/glusterfsd/src/glusterfsd.c:2421
#10 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#11 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
(gdb) t a a bt
Thread 9 (LWP 15288):
#0 0x00007fa565b32e3d in nanosleep () from ./lib64/libpthread.so.0
#1 0x00007fa566d11c77 in gf_timer_proc (data=0xe569d0) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/timer.c:194
#2 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#3 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 8 (LWP 15287):
#0 0x00007fa565b2cf47 in pthread_join () from ./lib64/libpthread.so.0
#1 0x00007fa566d7be2b in event_dispatch_epoll (event_pool=0xe4ee40) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/event-epoll.c:846
#2 0x00007fa566d38405 in event_dispatch (event_pool=0xe4ee40) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/event.c:116
#3 0x000000000040c019 in main (argc=1, argv=0x7fff6cf574a8) at
/home/jenkins/root/workspace/centos7-regression/glusterfsd/src/glusterfsd.c:2917
Thread 7 (LWP 15321):
#0 0x00007fa565b2f965 in pthread_cond_wait@@GLIBC_2.3.2 () from
./lib64/libpthread.so.0
#1 0x00007fa55aeb1b50 in hooks_worker (args=0xe61d70) at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-hooks.c:527
#2 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#3 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 6 (LWP 15293):
#0 0x00007fa5653e9f73 in select () from ./lib64/libc.so.6
#1 0x00007fa566d9a526 in runner (arg=0xe5b3c0) at
/home/jenkins/root/workspace/centos7-regression/contrib/timer-wheel/timer-wheel.c:186
#2 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#3 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 5 (LWP 15290):
#0 0x00007fa5653b9e2d in nanosleep () from ./lib64/libc.so.6
#1 0x00007fa5653b9cc4 in sleep () from ./lib64/libc.so.6
#2 0x00007fa566d399f8 in pool_sweeper (arg=0x0) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/mem-pool.c:446
#3 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#4 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 4 (LWP 15322):
#0 0x00007fa565b324ed in __lll_lock_wait () from ./lib64/libpthread.so.0
#1 0x00007fa565b2ddcb in _L_lock_883 () from ./lib64/libpthread.so.0
#2 0x00007fa565b2dc98 in pthread_mutex_lock () from ./lib64/libpthread.so.0
#3 0x00007fa55aee982e in gd_peerinfo_find_from_hostname
(hoststr=0x7fa548007520 "builder204.int.aws.gluster.org")
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-peer-utils.c:650
#4 0x00007fa55aee7935 in glusterd_peerinfo_find_by_hostname
(hoststr=0x7fa548007520 "builder204.int.aws.gluster.org")
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-peer-utils.c:112
#5 0x00007fa55aee7b77 in glusterd_hostname_to_uuid (hostname=0x7fa548007520
"builder204.int.aws.gluster.org", uuid=0x7fa557cd2ab0 "")
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-peer-utils.c:154
#6 0x00007fa55ae024b7 in glusterd_volume_brickinfo_get (uuid=0x0,
hostname=0x7fa548007520 "builder204.int.aws.gluster.org",
path=0x7fa54800761f "/d/backends/patchy4", volinfo=0xed3760,
brickinfo=0x7fa557cd5c10)
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-utils.c:1611
#7 0x00007fa55ae0273e in glusterd_volume_brickinfo_get_by_brick
(brick=0x7fa548001bd5 "builder204.int.aws.gluster.org:/d/backends/patchy4",
volinfo=0xed3760,
brickinfo=0x7fa557cd5c10, construct_real_path=false) at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-utils.c:1655
#8 0x00007fa55addfb0f in get_brickinfo_from_brickid (
brickid=0x7fa550004640
"a2393496-9716-4c17-a016-8512a0b911a7:builder204.int.aws.gluster.org:/d/backends/patchy4",
brickinfo=0x7fa557cd5c10)
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-handler.c:6010
--Type for more, q to quit, c to continue without paging--
#9 0x00007fa55addfbf6 in __glusterd_brick_rpc_notify (rpc=0x7fa550004700,
mydata=0x7fa550004640, event=RPC_CLNT_DISCONNECT, data=0x0)
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-handler.c:6044
#10 0x00007fa55adccdb1 in glusterd_big_locked_notify (rpc=0x7fa550004700,
mydata=0x7fa550004640, event=RPC_CLNT_DISCONNECT, data=0x0,
notify_fn=0x7fa55addfb32 <__glusterd_brick_rpc_notify>) at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-handler.c:66
#11 0x00007fa55ade0581 in glusterd_brick_rpc_notify (rpc=0x7fa550004700,
mydata=0x7fa550004640, event=RPC_CLNT_DISCONNECT, data=0x0)
at
/home/jenkins/root/workspace/centos7-regression/xlators/mgmt/glusterd/src/glusterd-handler.c:6199
#12 0x00007fa566a9f668 in rpc_clnt_handle_disconnect (clnt=0x7fa550004700,
conn=0x7fa550004730)
at
/home/jenkins/root/workspace/centos7-regression/rpc/rpc-lib/src/rpc-clnt.c:826
#13 0x00007fa566a9f927 in rpc_clnt_notify (trans=0x7fa550004a80,
mydata=0x7fa550004730, event=RPC_TRANSPORT_DISCONNECT, data=0x7fa550004a80)
at
/home/jenkins/root/workspace/centos7-regression/rpc/rpc-lib/src/rpc-clnt.c:887
#14 0x00007fa566a9ba5b in rpc_transport_notify (this=0x7fa550004a80,
event=RPC_TRANSPORT_DISCONNECT, data=0x7fa550004a80)
at
/home/jenkins/root/workspace/centos7-regression/rpc/rpc-lib/src/rpc-transport.c:549
#15 0x00007fa559fedd8e in socket_event_poll_err (this=0x7fa550004a80, gen=1,
idx=3)
at
/home/jenkins/root/workspace/centos7-regression/rpc/rpc-transport/socket/src/socket.c:1385
#16 0x00007fa559ff3f17 in socket_event_handler (fd=7, idx=3, gen=1,
data=0x7fa550004a80, poll_in=1, poll_out=4, poll_err=16, event_thread_died=0
'\000')
at
/home/jenkins/root/workspace/centos7-regression/rpc/rpc-transport/socket/src/socket.c:3025
#17 0x00007fa566d7b680 in event_dispatch_epoll_handler (event_pool=0xe4ee40,
event=0x7fa557cd6140)
at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/event-epoll.c:648
#18 0x00007fa566d7bb99 in event_dispatch_epoll_worker (data=0xeed3e0) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/event-epoll.c:761
#19 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#20 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 3 (LWP 15292):
#0 0x00007fa565b2fd12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
./lib64/libpthread.so.0
#1 0x00007fa566d51f02 in syncenv_task (proc=0xe57600) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop.c:517
#2 0x00007fa566d520f7 in syncenv_processor (thdata=0xe57600) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop.c:584
#3 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#4 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 2 (LWP 15291):
#0 0x00007fa565b2fd12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
./lib64/libpthread.so.0
#1 0x00007fa566d51f02 in syncenv_task (proc=0xe57240) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop.c:517
#2 0x00007fa566d520f7 in syncenv_processor (thdata=0xe57240) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop.c:584
#3 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#4 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
Thread 1 (LWP 15289):
#0 0x00007fa56532b207 in raise () from ./lib64/libc.so.6
#1 0x00007fa56532c8f8 in abort () from ./lib64/libc.so.6
#2 0x00007fa56536dd27 in __libc_message () from ./lib64/libc.so.6
#3 0x00007fa56536de0e in __libc_fatal () from ./lib64/libc.so.6
#4 0x00007fa56536e183 in _IO_vtable_check () from ./lib64/libc.so.6
#5 0x00007fa565372c9b in _IO_cleanup () from ./lib64/libc.so.6
#6 0x00007fa56532eb1b in __run_exit_handlers () from ./lib64/libc.so.6
#7 0x00007fa56532ebb7 in exit () from ./lib64/libc.so.6
#8 0x0000000000409485 in cleanup_and_exit (signum=15) at
/home/jenkins/root/workspace/centos7-regression/glusterfsd/src/glusterfsd.c:1659
#9 0x000000000040b093 in glusterfs_sigwaiter (arg=0x7fff6cf56250) at
/home/jenkins/root/workspace/centos7-regression/glusterfsd/src/glusterfsd.c:2421
#10 0x00007fa565b2bdd5 in start_thread () from ./lib64/libpthread.so.0
#11 0x00007fa5653f2ead in clone () from ./lib64/libc.so.6
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 05:18:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 05:18:31 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1619 from Worker Ant ---
REVIEW: https://review.gluster.org/22656 (glusterd: prevent use-after-free in
glusterd_op_ac_send_brick_op()) merged (#2) on master by Atin Mukherjee
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 10:33:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 10:33:23 +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 22665
--
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 May 6 10:33:24 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 10:33:24 +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 #647 from Worker Ant ---
REVIEW: https://review.gluster.org/22665 (libglusterfs: Fix compilation when
--disable-mempool is used) posted (#1) for review on master by Pranith Kumar
Karampuri
--
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 May 6 10:49:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 10:49:43 +0000
Subject: [Bugs] [Bug 1705884] Image size as reported from the fuse mount is
incorrect
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1705884
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22655 (features/shard: Fix integer overflow
in block count accounting) merged (#2) on master by Xavi Hernandez
--
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 Mon May 6 10:56:47 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 10:56:47 +0000
Subject: [Bugs] [Bug 1703020] The cluster.heal-timeout option is unavailable
for ec volume
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1703020
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-05-06 10:56:47
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22622 (cluster/ec: fix shd healer wait
timeout) merged (#2) 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 Mon May 6 11:39:59 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 11:39:59 +0000
Subject: [Bugs] [Bug 1706842] New: Hard Failover with Samba and Glusterfs
fails
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706842
Bug ID: 1706842
Summary: Hard Failover with Samba and Glusterfs fails
Product: GlusterFS
Version: 5
Status: NEW
Component: gluster-smb
Assignee: bugs at gluster.org
Reporter: david.spisla at iternity.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Created attachment 1564378
--> https://bugzilla.redhat.com/attachment.cgi?id=1564378&action=edit
Backtrace of the SMBD and GLUSTER communication
Description of problem:
I have this setup: 4-Node Glusterfs v5.5 Cluster, using SAMBA/CTDB v4.8 to
access the volumes via vfs-glusterfs-plugin (each node has a VIP)
I was testing this failover scenario:
1. Start Writing 940 GB with small files (64K-100K)from a Win10 Client to node1
2. During the write process I hardly shutdown node1 (where the client is
connect via VIP) by turn off the power
My expectation is, that the write process stops and after a while the Win10
Client offers me a Retry, so I can continue the write on different node (which
has now the VIP of node1). In past time I did this observation (with Gluster
v3.12), but now the system shows a strange bahaviour:
The Win10 Client do nothing and the Explorer freezes, in the backend CTDB can
not perform the failover and throws errors. The glusterd from node2 and node3
logs this messages:
[2019-04-16 14:47:31.828323] W [glusterd-locks.c:795:glusterd_mgmt_v3_unlock]
(-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x24349) [0x7f1a62fcb349]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x2d950) [0x7f1a62fd4950]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0xe0359) [0x7f1a63087359]
) 0-management: Lock for vol archive1 not held
[2019-04-16 14:47:31.828350] W [MSGID: 106117]
[glusterd-handler.c:6451:__glusterd_peer_rpc_notify] 0-management: Lock not
released for archive1
[2019-04-16 14:47:31.828369] W [glusterd-locks.c:795:glusterd_mgmt_v3_unlock]
(-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x24349) [0x7f1a62fcb349]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x2d950) [0x7f1a62fd4950]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0xe0359) [0x7f1a63087359]
) 0-management: Lock for vol archive2 not held
[2019-04-16 14:47:31.828376] W [MSGID: 106117]
[glusterd-handler.c:6451:__glusterd_peer_rpc_notify] 0-management: Lock not
released for archive2
[2019-04-16 14:47:31.828412] W [glusterd-locks.c:795:glusterd_mgmt_v3_unlock]
(-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x24349) [0x7f1a62fcb349]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0x2d950) [0x7f1a62fd4950]
-->/usr/lib64/glusterfs/5.5/xlator/mgmt/glusterd.so(+0xe0359) [0x7f1a63087359]
) 0-management: Lock for vol gluster_shared_storage not held
[2019-04-16 14:47:31.828423] W [MSGID: 106117]
[glusterd-handler.c:6451:__glusterd_peer_rpc_notify] 0-management: Lock not
released for gluster_shared_storage
In my oponion Samba/CTDB can not perform the failover correctly and continue
the write process because glusterfs didn't released the lock. But its not clear
to me
Additional info:
I made a network trace on the Windows machine.
There it is visible that the client tries several times a TreeConnect.
This Tree Connect is the connection to a share. Samba answers this attempt with
NT_STATUS_UNSUCCESSFUL, which was unfortunately a not very meaningful message.
Similarly, I "caught" the smbd in the debugger and was able to pull a backtrace
while hangs in the futex-call we found in / proc / / stack. The backtrace
smbd-gluster-bt.txt (attached) shows that the smbd hangs in the gluster module.
You can see in Frame 9 that Samba is hanging in the TCON
(smbd_smb2_tree_connect). In frame 2 the function appears
glfs_init () whose call you can find in source3 / modules / vfs_glusterfs.c,
line 342 (in samba master). Then comes another frame in the gluster-lib and
then immediately the pthread_condwait call, which ends up in the kernel in a
futex call (see / proc / / stack).
Quintessence: Samba is waiting for gluster, and obviously pretty much 3
seconds. Gluster then gives an error and the client tries again. And obviously
for 8 minutes.
--
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 May 6 11:43:21 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 11:43:21 +0000
Subject: [Bugs] [Bug 1706842] Hard Failover with Samba and Glusterfs fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706842
--- Comment #1 from david.spisla at iternity.com ---
Here is the Volume configuration:
Volume Name: archive1
Type: Replicate
Volume ID: 0ed37705-e817-49c6-95c8-32f4931b597a
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 4 = 4
Transport-type: tcp
Bricks:
Brick1: fs-sernet-c2-n1:/gluster/brick1/glusterbrick
Brick2: fs-sernet-c2-n2:/gluster/brick1/glusterbrick
Brick3: fs-sernet-c2-n3:/gluster/brick1/glusterbrick
Brick4: fs-sernet-c2-n4:/gluster/brick1/glusterbrick
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
user.smb: disable
features.read-only: off
features.worm: off
features.worm-file-level: on
features.retention-mode: enterprise
features.default-retention-period: 120
network.ping-timeout: 10
features.cache-invalidation: on
features.cache-invalidation-timeout: 600
performance.nl-cache: on
performance.nl-cache-timeout: 600
client.event-threads: 32
server.event-threads: 32
cluster.lookup-optimize: on
performance.stat-prefetch: on
performance.cache-invalidation: on
performance.md-cache-timeout: 600
performance.cache-samba-metadata: on
performance.cache-ima-xattrs: on
performance.io-thread-count: 64
cluster.use-compound-fops: on
performance.cache-size: 512MB
performance.cache-refresh-timeout: 10
performance.read-ahead: off
performance.write-behind-window-size: 4MB
performance.write-behind: on
storage.build-pgfid: on
features.utime: on
storage.ctime: on
cluster.quorum-type: fixed
cluster.quorum-count: 2
features.bitrot: on
features.scrub: Active
features.scrub-freq: daily
cluster.enable-shared-storage: 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 Mon May 6 13:02:09 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:02:09 +0000
Subject: [Bugs] [Bug 1706893] New: Volume stop when quorum not met is
successful
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
Bug ID: 1706893
Summary: Volume stop when quorum not met is successful
Product: Red Hat Gluster Storage
Version: rhgs-3.5
Hardware: x86_64
OS: Linux
Status: NEW
Component: glusterd
Keywords: Triaged
Severity: medium
Assignee: amukherj at redhat.com
Reporter: kiyer at redhat.com
QA Contact: bmekala at redhat.com
CC: amukherj at redhat.com, bugs at gluster.org,
rhs-bugs at redhat.com, risjain at redhat.com,
sankarshan at redhat.com, srakonde at redhat.com,
storage-qa-internal at redhat.com, vbellur at redhat.com
Depends On: 1690753
Target Milestone: ---
Classification: Red Hat
+++ This bug was initially created as a clone of Bug #1690753 +++
Description of problem:
On a 2 node cluster(N1 &N2), create one volume of type distributed. Now set
cluster.server-quorum-ratio to 90% and set cluster.server-quorum-type to
server. Start the volume and stop glusterd on one of the node. Now if you try
to stop the volume the volumes stops successfully but ideally it shouldn't
stop.
How reproducible:
5/5
Steps to Reproduce:
1. Create a cluster with 2 nodes.
2. Create a volume of type distributed.
3. Set cluster.server-quorum-ratio to 90.
4. Set server-quorum-type to server.
5. Start the volume.
6. Stop glusterd on one node.
7. Stop the volume.(Should fail!)
Actual results:
volume stop: testvol_distributed: success
Expected results:
volume stop: testvol_distributed: failed: Quorum not met. Volume operation not
allowed.
Additional info:
--- Additional comment from Atin Mukherjee on 2019-04-01 14:33:42 UTC ---
This looks like a bug and should be an easy fix.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1690753
[Bug 1690753] Volume stop when quorum not met is successful
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 13:02:09 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:02:09 +0000
Subject: [Bugs] [Bug 1690753] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1690753
Kshithij Iyer changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1706893
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
[Bug 1706893] Volume stop when quorum not met is successful
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 13:02:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:02:12 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
RHEL Product and Program Management changed:
What |Removed |Added
----------------------------------------------------------------------------
Rule Engine Rule| |Gluster: set proposed
| |release flag for new BZs at
| |RHGS
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 13:09:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:09:41 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
Kshithij Iyer changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |Regression
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 13:09:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:09:43 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
RHEL Product and Program Management changed:
What |Removed |Added
----------------------------------------------------------------------------
Rule Engine Rule| |Gluster: Block proposed
| |regressions at RHGS
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 13:58:26 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:58:26 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1620 from Worker Ant ---
REVIEW: https://review.gluster.org/22661 (glusterd: coverity fix) merged (#3)
on master by Amar Tumballi
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Mon May 6 13:58:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:58:50 +0000
Subject: [Bugs] [Bug 1693692] Increase code coverage from regression tests
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1693692
--- Comment #36 from Worker Ant ---
REVIEW: https://review.gluster.org/22550 (tests: validate volfile grammar -
strings in volfile) merged (#9) 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 May 6 13:59:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 13:59:13 +0000
Subject: [Bugs] [Bug 1704888] delete the snapshots and volume at the end of
uss.t
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1704888
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|POST |CLOSED
Resolution|--- |NEXTRELEASE
Last Closed| |2019-05-06 13:59:13
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22649 (tests: delete the snapshots and the
volume after the tests) merged (#4) 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 May 6 14:00:23 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 14:00:23 +0000
Subject: [Bugs] [Bug 1704888] delete the snapshots and volume at the end of
uss.t
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1704888
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |POST
CC| |atumball at redhat.com
Resolution|NEXTRELEASE |---
Keywords| |Reopened
--
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 May 6 10:33:24 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 10:33:24 +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 #648 from Worker Ant ---
REVIEW: https://review.gluster.org/22274 (mem-pool.{c|h}: minor changes) merged
(#18) 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 May 6 14:11:08 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 14:11:08 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
Atin Mukherjee changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vpandey at redhat.com
Flags| |needinfo?(vpandey at redhat.co
| |m)
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 15:14:47 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 15:14:47 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
Rahul Hinduja changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |asriram at redhat.com,
| |rhinduja at redhat.com
Blocks| |1696803
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 15:14:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 15:14:50 +0000
Subject: [Bugs] [Bug 1706683] Enable enable fips-mode-rchecksum for new
volumes by default
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706683
RHEL Product and Program Management changed:
What |Removed |Added
----------------------------------------------------------------------------
Rule Engine Rule| |Gluster: Auto pm_ack+ for
| |devel & qe approved BZs at
| |RHGS 3.5.0
Rule Engine Rule| |665
Target Release|--- |RHGS 3.5.0
Rule Engine Rule| |666
Rule Engine Rule| |327
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 17:09:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 17:09:44 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
--- Comment #5 from Vishal Pandey ---
Will start working on it ASAP.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 17:11:08 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 17:11:08 +0000
Subject: [Bugs] [Bug 1706893] Volume stop when quorum not met is successful
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706893
Vishal Pandey changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|amukherj at redhat.com |vpandey at redhat.com
Flags|needinfo?(vpandey at redhat.co |
|m) |
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Mon May 6 18:07:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 18:07:50 +0000
Subject: [Bugs] [Bug 1706842] Hard Failover with Samba and Glusterfs fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706842
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |high
--
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 May 6 18:25:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 18:25:27 +0000
Subject: [Bugs] [Bug 1707081] New: Self heal daemon not coming up after
upgrade to glusterfs-6.0-2 (intermittently) on a brick mux setup
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707081
Bug ID: 1707081
Summary: Self heal daemon not coming up after upgrade to
glusterfs-6.0-2 (intermittently) on a brick mux setup
Product: GlusterFS
Version: mainline
Status: NEW
Component: glusterd
Keywords: AutomationBlocker, Regression, TestBlocker
Severity: high
Assignee: bugs at gluster.org
Reporter: rkavunga at redhat.com
CC: amukherj at redhat.com, bmekala at redhat.com,
bugs at gluster.org, rhinduja at redhat.com,
rhs-bugs at redhat.com, rkavunga at redhat.com,
sankarshan at redhat.com, storage-qa-internal at redhat.com,
ubansal at redhat.com, vbellur at redhat.com
Depends On: 1704851
Blocks: 1696807
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1704851
[Bug 1704851] Self heal daemon not coming up after upgrade to glusterfs-6.0-2
(intermittently) on a brick mux 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 Mon May 6 18:26:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 18:26:02 +0000
Subject: [Bugs] [Bug 1707081] Self heal daemon not coming up after upgrade
to glusterfs-6.0-2 (intermittently) on a brick mux setup
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707081
Mohammed Rafi KC changed:
What |Removed |Added
----------------------------------------------------------------------------
Comment #0 is|1 |0
private| |
Status|NEW |ASSIGNED
QA Contact| |rkavunga 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 May 6 18:29:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 18:29:02 +0000
Subject: [Bugs] [Bug 1707081] Self heal daemon not coming up after upgrade
to glusterfs-6.0-2 (intermittently) on a brick mux setup
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707081
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22667
--
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 May 6 18:29:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Mon, 06 May 2019 18:29:03 +0000
Subject: [Bugs] [Bug 1707081] Self heal daemon not coming up after upgrade
to glusterfs-6.0-2 (intermittently) on a brick mux setup
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707081
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22667 (shd/glusterd: Serialize shd manager
to prevent race condition) posted (#2) for review on master by mohammed rafi
kc
--
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 May 7 02:46:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:46:05 +0000
Subject: [Bugs] [Bug 1707195] New: VM stuck in a shutdown because of a
pending fuse request
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Bug ID: 1707195
Summary: VM stuck in a shutdown because of a pending fuse
request
Product: GlusterFS
Version: 6
OS: Linux
Status: NEW
Component: write-behind
Severity: medium
Priority: medium
Assignee: bugs at gluster.org
Reporter: rgowdapp at redhat.com
CC: bugs at gluster.org, nravinas at redhat.com,
rgowdapp at redhat.com, rhinduja at redhat.com,
rhs-bugs at redhat.com, sankarshan at redhat.com
Depends On: 1702686, 1705865
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1705865
[Bug 1705865] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 02:48:00 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:48:00 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
--- Comment #1 from Raghavendra G ---
VM fails to shutdown, getting stuck in 'Powering down' status. This is because
its 'qemu-kvm' process gets in a zombie/defunct state:
more ps-Ll.txt
F S UID PID PPID LWP C PRI NI ADDR SZ WCHAN TTY TIME CMD
6 Z 107 20631 1 20631 0 80 0 - 0 do_exi ? 8:45
[qemu-kvm]
3 D 107 20631 1 20635 0 80 0 - 2386845 fuse_r ? 1:12
[qemu-kvm]
The customer has collected a crash dump of the affected VM and also statedumps
from all the glusterfs process running in this machine when this problem is
present.
Thread ID 20635 is the one of interest:
crash> bt 20635
PID: 20635 TASK: ffff9ed3926eb0c0 CPU: 7 COMMAND: "IO iothread1"
#0 [ffff9ec8e351fa28] __schedule at ffffffff91967747
#1 [ffff9ec8e351fab0] schedule at ffffffff91967c49
#2 [ffff9ec8e351fac0] __fuse_request_send at ffffffffc09d24e5 [fuse]
#3 [ffff9ec8e351fb30] fuse_request_send at ffffffffc09d26e2 [fuse]
#4 [ffff9ec8e351fb40] fuse_send_write at ffffffffc09dbc76 [fuse]
#5 [ffff9ec8e351fb70] fuse_direct_io at ffffffffc09dc0d6 [fuse]
#6 [ffff9ec8e351fc58] __fuse_direct_write at ffffffffc09dc562 [fuse]
#7 [ffff9ec8e351fca8] fuse_direct_IO at ffffffffc09dd3ca [fuse]
#8 [ffff9ec8e351fd70] generic_file_direct_write at ffffffff913b8663
#9 [ffff9ec8e351fdc8] fuse_file_aio_write at ffffffffc09ddbd5 [fuse]
#10 [ffff9ec8e351fe60] do_io_submit at ffffffff91497a73
#11 [ffff9ec8e351ff40] sys_io_submit at ffffffff91497f40
#12 [ffff9ec8e351ff50] tracesys at ffffffff9197505b (via system_call)
RIP: 00007f9ff0758697 RSP: 00007f9db86814b8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: ffffffffffffffff
RDX: 00007f9db86814d0 RSI: 0000000000000001 RDI: 00007f9ff268e000
RBP: 0000000000000080 R8: 0000000000000080 R9: 000000000000006a
R10: 0000000000000078 R11: 0000000000000246 R12: 00007f9db86814c0
R13: 0000560264b9b518 R14: 0000560264b9b4f0 R15: 00007f9db8681bb0
ORIG_RAX: 00000000000000d1 CS: 0033 SS: 002b
>From the core, this is the file the above process is writing to:
crash> files -d 0xffff9ec8e8f9f740
DENTRY INODE SUPERBLK TYPE PATH
ffff9ec8e8f9f740 ffff9ed39e705700 ffff9ee009adc000 REG
/rhev/data-center/mnt/glusterSD/172.16.20.21:_vmstore2/e5dd645f-88bb-491c-9145-38fa229cbc4d/images/8e84c1ed-48ba-4b82-9882-c96e6f260bab/29bba0a1-6c7b-4358-9ef2-f8080405778d
So in this case we're accessing the vmstore2 volume.
This is the glusterfs process:
root 4863 0.0 0.0 1909580 49316 ? S bt 4863
PID: 4863 TASK: ffff9edfa9ff9040 CPU: 11 COMMAND: "glusterfs"
#0 [ffff9ed3a332fc28] __schedule at ffffffff91967747
#1 [ffff9ed3a332fcb0] schedule at ffffffff91967c49
#2 [ffff9ed3a332fcc0] futex_wait_queue_me at ffffffff9130cf76
#3 [ffff9ed3a332fd00] futex_wait at ffffffff9130dc5b
#4 [ffff9ed3a332fe48] do_futex at ffffffff9130f9a6
#5 [ffff9ed3a332fed8] sys_futex at ffffffff9130fec0
#6 [ffff9ed3a332ff50] system_call_fastpath at ffffffff91974ddb
RIP: 00007f6e5eeccf47 RSP: 00007ffdd311c7d0 RFLAGS: 00000246
RAX: 00000000000000ca RBX: 00007f6e59496700 RCX: ffffffffffffffff
RDX: 0000000000001308 RSI: 0000000000000000 RDI: 00007f6e594969d0
RBP: 00007f6e60552780 R8: 0000000000000000 R9: 00007f6e5e6e314d
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e59496d28
R13: 0000000000000000 R14: 0000000000000006 R15: 00007ffdd311c920
ORIG_RAX: 00000000000000ca CS: 0033 SS: 002b
We have a few pending frames in this process. Reviewing the corresponding
statedump:
grep complete=0 glusterdump.4863.dump.1556091368 -c
7
Looking for these pending frames in the statedump:
~~~
[global.callpool.stack.1]
stack=0x7f6e4007c828
uid=107
gid=107
pid=20635
unique=5518502
lk-owner=bd2351a6cc7fcb8b
op=WRITE
type=1
cnt=6
[global.callpool.stack.1.frame.1]
frame=0x7f6dec04de38
ref_count=0
translator=vmstore2-write-behind
complete=0
parent=vmstore2-open-behind
wind_from=default_writev_resume
wind_to=(this->children->xlator)->fops->writev
unwind_to=default_writev_cbk
[global.callpool.stack.1.frame.2]
frame=0x7f6dec0326f8
ref_count=1
translator=vmstore2-open-behind
complete=0
parent=vmstore2-md-cache
wind_from=mdc_writev
wind_to=(this->children->xlator)->fops->writev
unwind_to=mdc_writev_cbk
[global.callpool.stack.1.frame.3]
frame=0x7f6dec005bf8
ref_count=1
translator=vmstore2-md-cache
complete=0
parent=vmstore2-io-threads
wind_from=default_writev_resume
wind_to=(this->children->xlator)->fops->writev
unwind_to=default_writev_cbk
[global.callpool.stack.1.frame.4]
frame=0x7f6e400ab0f8
ref_count=1
translator=vmstore2-io-threads
complete=0
parent=vmstore2
wind_from=io_stats_writev
wind_to=(this->children->xlator)->fops->writev
unwind_to=io_stats_writev_cbk
[global.callpool.stack.1.frame.5]
frame=0x7f6e4007c6c8
ref_count=1
translator=vmstore2
complete=0
parent=fuse
wind_from=fuse_write_resume
wind_to=FIRST_CHILD(this)->fops->writev
unwind_to=fuse_writev_cbk
[global.callpool.stack.1.frame.6]
frame=0x7f6e4002cb98
ref_count=1
translator=fuse
complete=0
~~~
So I believe we're pending in the 'write-behind' translator. Please, I'd need
some help to figure out the cause of the hang.
Thank you,
Natalia
--
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 May 7 02:48:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:48:45 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Raghavendra G changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #2 from Raghavendra G ---
I do see a write request hung in write-behind. Details of write-request from
state-dump:
[xlator.performance.write-behind.wb_inode]
path=/e5dd645f-88bb-491c-9145-38fa229cbc4d/images/8e84c1ed-48ba-4b82-9882-c96e6f260bab/29bba0a1-6c7b-4358-9ef2-f8080405778d
inode=0x7f6e40060888
gfid=6348d15d-7b17-4993-9da9-3f588c2ad5a8
window_conf=1048576
window_current=0
transit-size=0
dontsync=0
[.WRITE]
unique=5518502
refcount=1
wound=no
generation-number=0
req->op_ret=131072
req->op_errno=0
sync-attempts=0
sync-in-progress=no
size=131072
offset=4184756224
lied=0
append=0
fulfilled=0
go=0
I'll go through this and will try to come up with an RCA.
--- Additional comment from Raghavendra G on 2019-04-29 07:21:50 UTC ---
There is a race in the way O_DIRECT writes are handled. Assume two overlapping
write requests w1 and w2.
* w1 is issued and is in wb_inode->wip queue as the response is still pending
from bricks. Also wb_request_unref in wb_do_winds is not yet invoked.
list_for_each_entry_safe (req, tmp, tasks, winds) {
list_del_init (&req->winds);
if (req->op_ret == -1) {
call_unwind_error_keep_stub (req->stub, req->op_ret,
req->op_errno);
} else {
call_resume_keep_stub (req->stub);
}
wb_request_unref (req);
}
* w2 is issued and wb_process_queue is invoked. w2 is not picked up for winding
as w1 is still in wb_inode->wip. w1 is added to todo list and wb_writev for w2
returns.
* response to w1 is received and invokes wb_request_unref. Assume
wb_request_unref in wb_do_winds (see point 1) is not invoked yet. Since there
is one more refcount, wb_request_unref in wb_writev_cbk of w1 doesn't remove w1
from wip.
* wb_process_queue is invoked as part of wb_writev_cbk of w1. But, it fails to
wind w2 as w1 is still in wip.
* wb_requet_unref is invoked on w1 as part of wb_do_winds. w1 is removed from
all queues including w1.
* After this point there is no invocation of wb_process_queue unless new
request is issued from application causing w2 to be hung till the next request.
This bug is similar to bz 1626780 and bz 1379655. Though the issue is similar,
fixes to these to bzs won't fix the current bug and hence this bug is not a
duplicate. This bug will require a new fix and I'll post a patch to gerrit
shortly.
--
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 May 7 02:50:49 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:50:49 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22668
--
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 May 7 02:50:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:50:50 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
--- Comment #3 from Worker Ant ---
REVIEW: https://review.gluster.org/22668 (performance/write-behind: remove
request from wip list in wb_writev_cbk) posted (#1) for review on release-6 by
Raghavendra G
--
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 May 7 02:51:11 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:51:11 +0000
Subject: [Bugs] [Bug 1707198] New: VM stuck in a shutdown because of a
pending fuse request
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
Bug ID: 1707198
Summary: VM stuck in a shutdown because of a pending fuse
request
Product: GlusterFS
Version: 5
OS: Linux
Status: NEW
Component: write-behind
Severity: medium
Priority: medium
Assignee: bugs at gluster.org
Reporter: rgowdapp at redhat.com
CC: bugs at gluster.org, nravinas at redhat.com,
rgowdapp at redhat.com, rhinduja at redhat.com,
rhs-bugs at redhat.com, sankarshan at redhat.com
Depends On: 1702686, 1705865
Blocks: 1707195
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1705865
[Bug 1705865] VM stuck in a shutdown because of a pending fuse request
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
[Bug 1707195] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 02:51:11 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:51:11 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Raghavendra G changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends On| |1707198
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
[Bug 1707198] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 02:53:40 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:53:40 +0000
Subject: [Bugs] [Bug 1707198] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22669
--
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 May 7 02:53:41 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:53:41 +0000
Subject: [Bugs] [Bug 1707198] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22669 (performance/write-behind: remove
request from wip list in wb_writev_cbk) posted (#1) for review on release-5 by
Raghavendra G
--
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 May 7 02:54:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:54:05 +0000
Subject: [Bugs] [Bug 1707200] New: VM stuck in a shutdown because of a
pending fuse request
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707200
Bug ID: 1707200
Summary: VM stuck in a shutdown because of a pending fuse
request
Product: GlusterFS
Version: 4.1
OS: Linux
Status: NEW
Component: write-behind
Severity: medium
Priority: medium
Assignee: bugs at gluster.org
Reporter: rgowdapp at redhat.com
CC: bugs at gluster.org, nravinas at redhat.com,
rgowdapp at redhat.com, rhinduja at redhat.com,
rhs-bugs at redhat.com, sankarshan at redhat.com
Depends On: 1702686, 1707195, 1707198, 1705865
Target Milestone: ---
Classification: Community
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1705865
[Bug 1705865] VM stuck in a shutdown because of a pending fuse request
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
[Bug 1707195] VM stuck in a shutdown because of a pending fuse request
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
[Bug 1707198] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 02:54:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:54:05 +0000
Subject: [Bugs] [Bug 1707195] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707195
Raghavendra G changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1707200
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1707200
[Bug 1707200] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 02:54:05 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 02:54:05 +0000
Subject: [Bugs] [Bug 1707198] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707198
Raghavendra G changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1707200
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1707200
[Bug 1707200] VM stuck in a shutdown because of a pending fuse request
--
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 May 7 05:12:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 05:12:31 +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 #649 from Worker Ant ---
REVIEW: https://review.gluster.org/22665 (libglusterfs: Fix compilation when
--disable-mempool is used) merged (#2) on master by Pranith Kumar Karampuri
--
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 May 7 05:17:07 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 05:17:07 +0000
Subject: [Bugs] [Bug 1707200] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707200
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22670
--
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 May 7 05:17:08 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 05:17:08 +0000
Subject: [Bugs] [Bug 1707200] VM stuck in a shutdown because of a pending
fuse request
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707200
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22670 (performance/write-behind: remove
request from wip list in wb_writev_cbk) posted (#1) for review on release-4.1
by Raghavendra G
--
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 May 7 05:36:53 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 05:36:53 +0000
Subject: [Bugs] [Bug 789278] Issues reported by Coverity static analysis tool
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=789278
--- Comment #1621 from Worker Ant ---
REVIEW: https://review.gluster.org/22610 (afr : fix Coverity CID 1398627)
merged (#7) on master by Pranith Kumar Karampuri
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Tue May 7 05:56:57 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 05:56:57 +0000
Subject: [Bugs] [Bug 1707227] New: glusterfsd memory leak after enable
tls/ssl
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707227
Bug ID: 1707227
Summary: glusterfsd memory leak after enable tls/ssl
Product: GlusterFS
Version: 4.1
Hardware: x86_64
OS: Linux
Status: NEW
Component: rpc
Severity: high
Assignee: bugs at gluster.org
Reporter: zz.sh.cynthia at gmail.com
CC: bugs at gluster.org
Target Milestone: ---
Classification: Community
Description of problem:
glusterfsd memory leak found
Version-Release number of selected component (if applicable):
3.12.15
How reproducible:
while true;do gluster v heal info;done
and open another session to check the memory usage of the related
glusterfsd process, the memory will keep increasing until around 370M then
increase will stop
Steps to Reproduce:
1.while true;do gluster v heal info;done
2.check the memory usage of the related glusterfsd process
3.
Actual results:
the memory will keep increasing until around 370M then increase will stop
Expected results:
memory stable
Additional info:
with memory scan tool vlagrand attached to glusterfsd process and libleak
attached to glusterfsd process seems ssl_accept is suspicious, not sure it is
caused by ssl_accept or glusterfs mis-use of ssl:
==16673== 198,720 bytes in 12 blocks are definitely lost in loss record 1,114
of 1,123
==16673== at 0x4C2EB7B: malloc (vg_replace_malloc.c:299)
==16673== by 0x63E1977: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.2p)
==16673== by 0xA855E0C: ssl3_setup_write_buffer (in
/usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA855E77: ssl3_setup_buffers (in /usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA8485D9: ssl3_accept (in /usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA610DDF: ssl_complete_connection (socket.c:400)
==16673== by 0xA617F38: ssl_handle_server_connection_attempt (socket.c:2409)
==16673== by 0xA618420: socket_complete_connection (socket.c:2554)
==16673== by 0xA618788: socket_event_handler (socket.c:2613)
==16673== by 0x4ED6983: event_dispatch_epoll_handler (event-epoll.c:587)
==16673== by 0x4ED6C5A: event_dispatch_epoll_worker (event-epoll.c:663)
==16673== by 0x615C5D9: start_thread (in /usr/lib64/libpthread-2.27.so)
==16673==
==16673== 200,544 bytes in 12 blocks are definitely lost in loss record 1,115
of 1,123
==16673== at 0x4C2EB7B: malloc (vg_replace_malloc.c:299)
==16673== by 0x63E1977: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.2p)
==16673== by 0xA855D12: ssl3_setup_read_buffer (in /usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA855E68: ssl3_setup_buffers (in /usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA8485D9: ssl3_accept (in /usr/lib64/libssl.so.1.0.2p)
==16673== by 0xA610DDF: ssl_complete_connection (socket.c:400)
==16673== by 0xA617F38: ssl_handle_server_connection_attempt (socket.c:2409)
==16673== by 0xA618420: socket_complete_connection (socket.c:2554)
==16673== by 0xA618788: socket_event_handler (socket.c:2613)
==16673== by 0x4ED6983: event_dispatch_epoll_handler (event-epoll.c:587)
==16673== by 0x4ED6C5A: event_dispatch_epoll_worker (event-epoll.c:663)
==16673== by 0x615C5D9: start_thread (in /usr/lib64/libpthread-2.27.so)
==16673==
valgrind --leak-check=f
also, with another memory leak scan tool libleak:
callstack[2419] expires. count=1 size=224/224 alloc=362 free=350
/home/robot/libleak/libleak.so(malloc+0x25) [0x7f1460604065]
/lib64/libcrypto.so.10(CRYPTO_malloc+0x58) [0x7f145ecd9978]
/lib64/libcrypto.so.10(EVP_DigestInit_ex+0x2a9) [0x7f145ed95749]
/lib64/libssl.so.10(ssl3_digest_cached_records+0x11d) [0x7f145abb6ced]
/lib64/libssl.so.10(ssl3_accept+0xc8f) [0x7f145abadc4f]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(ssl_complete_connection+0x5e)
[0x7f145ae00f3a]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc16d) [0x7f145ae0816d]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc68a) [0x7f145ae0868a]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc9f2) [0x7f145ae089f2]
/lib64/libglusterfs.so.0(+0x9b96f) [0x7f146038596f]
/lib64/libglusterfs.so.0(+0x9bc46) [0x7f1460385c46]
/lib64/libpthread.so.0(+0x75da) [0x7f145f0d15da]
/lib64/libc.so.6(clone+0x3f) [0x7f145e9a7eaf]
callstack[2432] expires. count=1 size=104/104 alloc=362 free=0
/home/robot/libleak/libleak.so(malloc+0x25) [0x7f1460604065]
/lib64/libcrypto.so.10(CRYPTO_malloc+0x58) [0x7f145ecd9978]
/lib64/libcrypto.so.10(BN_MONT_CTX_new+0x17) [0x7f145ed48627]
/lib64/libcrypto.so.10(BN_MONT_CTX_set_locked+0x6d) [0x7f145ed489fd]
/lib64/libcrypto.so.10(+0xff4d9) [0x7f145ed6a4d9]
/lib64/libcrypto.so.10(int_rsa_verify+0x1cd) [0x7f145ed6d41d]
/lib64/libcrypto.so.10(RSA_verify+0x32) [0x7f145ed6d972]
/lib64/libcrypto.so.10(+0x107ff5) [0x7f145ed72ff5]
/lib64/libcrypto.so.10(EVP_VerifyFinal+0x211) [0x7f145ed9dd51]
/lib64/libssl.so.10(ssl3_get_cert_verify+0x5bb) [0x7f145abac06b]
/lib64/libssl.so.10(ssl3_accept+0x988) [0x7f145abad948]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(ssl_complete_connection+0x5e)
[0x7f145ae00f3a]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc16d) [0x7f145ae0816d]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc68a) [0x7f145ae0868a]
/usr/lib64/glusterfs/3.12.15/rpc-transport/socket.so(+0xc9f2) [0x7f145ae089f2]
/lib64/libglusterfs.so.0(+0x9b96f) [0x7f146038596f]
/lib64/libglusterfs.so.0(+0x9bc46) [0x7f1460385c46]
/lib64/libpthread.so.0(+0x75da) [0x7f145f0d15da]
/lib64/libc.so.6(clone+0x3f) [0x7f145e9a7eaf]
--
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 May 7 06:06:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 06:06:45 +0000
Subject: [Bugs] [Bug 1698861] Renaming a directory when 2 bricks of multiple
disperse subvols are down leaves both old and new dirs on the bricks.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1698861
Ashish Pandey changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |aspandey at redhat.com
--- Comment #1 from Ashish Pandey ---
Steps -
1 - Create 4+2 volume and mount it on /mnt/vol
Volume Name: vol
Type: Disperse
Volume ID: 742b8e08-1f16-4bad-aa94-5e36dd10fe91
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (4 + 2) = 6
Transport-type: tcp
Bricks:
Brick1: apandey:/home/apandey/bricks/gluster/vol-1
Brick2: apandey:/home/apandey/bricks/gluster/vol-2
Brick3: apandey:/home/apandey/bricks/gluster/vol-3
Brick4: apandey:/home/apandey/bricks/gluster/vol-4
Brick5: apandey:/home/apandey/bricks/gluster/vol-5
Brick6: apandey:/home/apandey/bricks/gluster/vol-6
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
Status of volume: vol
Gluster process
2 - mkdir /mnt/vol/dir/old -p
3 -for i in {1..200}; do touch dir/old/file-$i ; done
[root at apandey glusterfs]# gluster v status
Status of volume: vol
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick apandey:/home/apandey/bricks/gluster/
vol-1 49152 0 Y 13401
Brick apandey:/home/apandey/bricks/gluster/
vol-2 49153 0 Y 11682
Brick apandey:/home/apandey/bricks/gluster/
vol-3 49154 0 Y 11702
Brick apandey:/home/apandey/bricks/gluster/
vol-4 49155 0 Y 11722
Brick apandey:/home/apandey/bricks/gluster/
vol-5 49156 0 Y 11742
Brick apandey:/home/apandey/bricks/gluster/
vol-6 49157 0 Y 11762
Self-heal Daemon on localhost N/A N/A Y 13427
Task Status of Volume vol
------------------------------------------------------------------------------
There are no active volume tasks
4 - Kill brick 1
[root at apandey glusterfs]# kill 13401
[root at apandey glusterfs]# gluster v status
Status of volume: vol
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick apandey:/home/apandey/bricks/gluster/
vol-1 N/A N/A N N/A
Brick apandey:/home/apandey/bricks/gluster/
vol-2 49153 0 Y 11682
Brick apandey:/home/apandey/bricks/gluster/
vol-3 49154 0 Y 11702
Brick apandey:/home/apandey/bricks/gluster/
vol-4 49155 0 Y 11722
Brick apandey:/home/apandey/bricks/gluster/
vol-5 49156 0 Y 11742
Brick apandey:/home/apandey/bricks/gluster/
vol-6 49157 0 Y 11762
Self-heal Daemon on localhost N/A N/A Y 13427
Task Status of Volume vol
------------------------------------------------------------------------------
There are no active volume tasks
5 - mv dir/old/ dir/new
6 - [root at apandey vol]# ll dir/new | wc -l
201
7 - gluster v start vol force
8 -ll dir/new | wc -l
1
9 - ll dir/old | wc -l
1
10-
[root at apandey glusterfs]# getfattr -m. -d -e hex
/home/apandey/bricks/gluster/vol-*/dir/old
getfattr: Removing leading '/' from absolute path names
# file: home/apandey/bricks/gluster/vol-1/dir/old
trusted.ec.dirty=0x00000000000000010000000000000001
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
# file: home/apandey/bricks/gluster/vol-2/dir/old
trusted.ec.dirty=0x00000000000000000000000000000000
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
# file: home/apandey/bricks/gluster/vol-3/dir/old
trusted.ec.dirty=0x00000000000000000000000000000000
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
# file: home/apandey/bricks/gluster/vol-4/dir/old
trusted.ec.dirty=0x00000000000000000000000000000000
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
# file: home/apandey/bricks/gluster/vol-5/dir/old
trusted.ec.dirty=0x00000000000000000000000000000000
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
# file: home/apandey/bricks/gluster/vol-6/dir/old
trusted.ec.dirty=0x00000000000000000000000000000000
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
11-
[root at apandey glusterfs]# getfattr -m. -d -e hex
/home/apandey/bricks/gluster/vol-*/dir/new
getfattr: Removing leading '/' from absolute path names
# file: home/apandey/bricks/gluster/vol-1/dir/new
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
# file: home/apandey/bricks/gluster/vol-2/dir/new
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
# file: home/apandey/bricks/gluster/vol-3/dir/new
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
# file: home/apandey/bricks/gluster/vol-4/dir/new
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
# file: home/apandey/bricks/gluster/vol-5/dir/new
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
# file: home/apandey/bricks/gluster/vol-6/dir/new
trusted.ec.version=0x00000000000000c800000000000000c8
trusted.gfid=0x098b8bf8e0ba406283f26334a0b83e23
trusted.glusterfs.dht=0x000000000000000000000000ffffffff
12 - [root at apandey glusterfs]# gluster v heal vol info
Brick apandey:/home/apandey/bricks/gluster/vol-1
Status: Connected
Number of entries: 0
Brick apandey:/home/apandey/bricks/gluster/vol-2
Status: Connected
Number of entries: 0
Brick apandey:/home/apandey/bricks/gluster/vol-3
Status: Connected
Number of entries: 0
Brick apandey:/home/apandey/bricks/gluster/vol-4
Status: Connected
Number of entries: 0
Brick apandey:/home/apandey/bricks/gluster/vol-5
Status: Connected
Number of entries: 0
Brick apandey:/home/apandey/bricks/gluster/vol-6
Status: Connected
Number of entries: 0
13 - As we can see that the
trusted.glusterfs.dht=0x000000000000000000000000ffffffff is missing for "old"
directory on all the 5 bricks, I set this xattr manually.
setfattr -n trusted.glusterfs.dht -v 0x000000000000000000000000ffffffff
/home/apandey/bricks/gluster/vol-{2..6}/dir/old
14 - I copied the data from new dir to old dir on respective bricks -
15 - for i in {2..6} ; do yes | cp -rf
/home/apandey/bricks/gluster/vol-$i/dir/new/*
/home/apandey/bricks/gluster/vol-$i/dir/old/; done
16 - After this files were visible on both the old and new dir
[root at apandey vol]# ll dir/new | wc -l
201
[root at apandey vol]# ll dir/old | wc -l
201
[root at apandey vol]#
17 - Although this will have both the directories, if we have all the data back
and all the bricks are UP, we can safely move the data in new directory.
This is working for the issue which we created using our set of steps. I am not
sure if this case is exactly similar to what user is experiencing or not.
--
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 May 7 08:25:44 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 08:25:44 +0000
Subject: [Bugs] [Bug 1679401] Geo-rep setup creates an incorrectly formatted
authorized_keys file
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1679401
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22673
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 08:25:45 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 08:25:45 +0000
Subject: [Bugs] [Bug 1679401] Geo-rep setup creates an incorrectly formatted
authorized_keys file
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1679401
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |POST
Resolution|NEXTRELEASE |---
Keywords| |Reopened
--- Comment #3 from Worker Ant ---
REVIEW: https://review.gluster.org/22673 (geo-rep: fix incorrectly formatted
authorized_keys) posted (#1) for review on master by Sunny Kumar
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 09:24:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 09:24:31 +0000
Subject: [Bugs] [Bug 1654753] A distributed-disperse volume crashes when a
symbolic link is renamed
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1654753
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22666
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 09:24:32 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 09:24:32 +0000
Subject: [Bugs] [Bug 1654753] A distributed-disperse volume crashes when a
symbolic link is renamed
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1654753
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22666 (dht: use separate inode for linkto
file create and setattr) posted (#2) for review on master by Susant Palai
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 09:28:26 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 09:28:26 +0000
Subject: [Bugs] [Bug 1702316] Cannot upgrade 5.x volume to 6.1 because of
unused 'crypt' and 'bd' xlators
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1702316
robdewit changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Github
| |gluster/glusterfs/issues/66
| |5
--
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 May 7 10:11:28 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 10:11:28 +0000
Subject: [Bugs] [Bug 1706842] Hard Failover with Samba and Glusterfs fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706842
--- Comment #2 from david.spisla at iternity.com ---
Additional information: In the section "Description of problem" above there are
shown log entries from glusterd while failover happens. These logs are from
2019-04-16. But the backtrace was created on 2019-04-30 and the attached logs
of the glusterfs-plugin from all nodes contains information from 2019-04-30.
Don't get irritated! The messages in glusterd are reproducible so one can find
them also in 2019-04-30.
--
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 May 7 10:14:19 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 10:14:19 +0000
Subject: [Bugs] [Bug 1706842] Hard Failover with Samba and Glusterfs fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706842
--- Comment #3 from david.spisla at iternity.com ---
Created attachment 1565074
--> https://bugzilla.redhat.com/attachment.cgi?id=1565074&action=edit
Logfiles from all nodes of glusterfs-plugin (SMB)
--
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 May 7 12:00:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:00:43 +0000
Subject: [Bugs] [Bug 1703343] Bricks fail to come online after node reboot
on a scaled setup
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1703343
Raghavendra Talur changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1638192
Depends On|1638192 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1638192
[Bug 1638192] Bricks fail to come online after node reboot on a scaled setup
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 12:01:18 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:01:18 +0000
Subject: [Bugs] [Bug 1703343] Bricks fail to come online after node reboot
on a scaled setup
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1703343
Raghavendra Talur changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|1637968 |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1637968
[Bug 1637968] [RHGS] [Glusterd] Bricks fail to come online after node reboot on
a scaled setup
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 12:22:49 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:22:49 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Pranith Kumar K changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |POST
Resolution|NEXTRELEASE |---
Keywords| |Reopened
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Tue May 7 12:25:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:25:27 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22674
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Tue May 7 12:25:28 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:25:28 +0000
Subject: [Bugs] [Bug 1706603] Glusterfsd crashing in ec-inode-write.c,
in GF_ASSERT
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1706603
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22674 (tests: Test openfd heal doesn't
truncate files) posted (#1) for review on master by Pranith Kumar Karampuri
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla at redhat.com Tue May 7 12:39:33 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:39:33 +0000
Subject: [Bugs] [Bug 1707393] New: Refactor dht lookup code
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707393
Bug ID: 1707393
Summary: Refactor dht lookup code
Product: GlusterFS
Version: 6
Status: NEW
Component: distribute
Keywords: Reopened
Severity: medium
Priority: high
Assignee: bugs at gluster.org
Reporter: nbalacha at redhat.com
CC: bugs at gluster.org
Depends On: 1590385
Blocks: 1703897
Target Milestone: ---
Classification: Community
+++ This bug was initially created as a clone of Bug #1590385 +++
Description of problem:
Refactor the dht lookup code in order to make it easier to maintain.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--- Additional comment from Worker Ant on 2018-06-12 14:24:47 UTC ---
REVIEW: https://review.gluster.org/20246 (cluster/dht: refactor dht_lookup)
posted (#1) for review on master by N Balachandran
--- Additional comment from Worker Ant on 2018-06-14 07:09:47 UTC ---
REVIEW: https://review.gluster.org/20267 (cluster/dht: Minor code cleanup)
posted (#1) for review on master by N Balachandran
--- Additional comment from Worker Ant on 2018-06-20 02:40:18 UTC ---
COMMIT: https://review.gluster.org/20267 committed in master by "N
Balachandran" with a commit message- cluster/dht: Minor
code cleanup
Removed extra variable.
Change-Id: If43c47f6630454aeadab357a36d061ec0b53cdb5
updates: bz#1590385
Signed-off-by: N Balachandran
--- Additional comment from Worker Ant on 2018-06-21 05:36:13 UTC ---
COMMIT: https://review.gluster.org/20246 committed in master by "Amar Tumballi"
with a commit message- cluster/dht: refactor dht_lookup
The dht lookup code is getting difficult to maintain
due to its size. Refactoring the code will make it
easier to modify it in future.
Change-Id: Ic7cb5bf4f018504dfaa7f0d48cf42ab0aa34abdd
updates: bz#1590385
Signed-off-by: N Balachandran
--- Additional comment from Worker Ant on 2018-08-02 16:20:48 UTC ---
REVIEW: https://review.gluster.org/20622 (cluster/dht: refactor dht_lookup_cbk)
posted (#1) for review on master by N Balachandran
--- Additional comment from Shyamsundar on 2018-10-23 15:11:13 UTC ---
This bug is getting closed because a release has been made available that
should address the reported issue. In case the problem is still not fixed with
glusterfs-5.0, please open a new bug report.
glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for
several distributions should become available in the near future. Keep an eye
on the Gluster Users mailinglist [2] and the update infrastructure for your
distribution.
[1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html
[2] https://www.gluster.org/pipermail/gluster-users/
--- Additional comment from Nithya Balachandran on 2018-10-29 02:58:27 UTC ---
Reopening as this is an umbrella BZ for many more changes to the rebalance
process.
--- Additional comment from Worker Ant on 2018-12-06 13:57:38 UTC ---
REVIEW: https://review.gluster.org/21816 (cluster/dht: refactor dht_lookup_cbk)
posted (#1) for review on master by N Balachandran
--- Additional comment from Worker Ant on 2018-12-26 12:41:37 UTC ---
REVIEW: https://review.gluster.org/21816 (cluster/dht: refactor dht_lookup_cbk)
posted (#7) for review on master by N Balachandran
--- Additional comment from Nithya Balachandran on 2018-12-26 12:56:32 UTC ---
Reopening this as there will be more changes.
--- Additional comment from Worker Ant on 2019-03-25 10:29:50 UTC ---
REVIEW: https://review.gluster.org/22407 (cluster/dht: refactor dht lookup
functions) posted (#1) for review on master by N Balachandran
--- Additional comment from Shyamsundar on 2019-03-25 16:30:27 UTC ---
This bug is getting closed because a release has been made available that
should address the reported issue. In case the problem is still not fixed with
glusterfs-6.0, please open a new bug report.
glusterfs-6.0 has been announced on the Gluster mailinglists [1], packages for
several distributions should become available in the near future. Keep an eye
on the Gluster Users mailinglist [2] and the update infrastructure for your
distribution.
[1] https://lists.gluster.org/pipermail/announce/2019-March/000120.html
[2] https://www.gluster.org/pipermail/gluster-users/
--- Additional comment from Worker Ant on 2019-04-06 01:41:34 UTC ---
REVIEW: https://review.gluster.org/22407 (cluster/dht: refactor dht lookup
functions) merged (#10) on master by N Balachandran
--- Additional comment from Worker Ant on 2019-04-10 09:03:15 UTC ---
REVIEW: https://review.gluster.org/22542 (cluster/dht: Refactor dht lookup
functions) posted (#1) for review on master by N Balachandran
--- Additional comment from Worker Ant on 2019-04-25 04:12:37 UTC ---
REVIEW: https://review.gluster.org/22542 (cluster/dht: Refactor dht lookup
functions) merged (#3) on master by Amar Tumballi
--- Additional comment from Nithya Balachandran on 2019-04-29 03:21:31 UTC ---
Marking this Modified as I am done with the changes for now.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1590385
[Bug 1590385] Refactor dht lookup 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 Tue May 7 12:39:33 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:39:33 +0000
Subject: [Bugs] [Bug 1590385] Refactor dht lookup code
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1590385
Nithya Balachandran changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |1707393
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1707393
[Bug 1707393] Refactor dht lookup code
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 12:51:49 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:51:49 +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 22675
--
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 May 7 12:51:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:51:50 +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 #650 from Worker Ant ---
REVIEW: https://review.gluster.org/22675 ([WIP]glusterd-utils.c: skip checksum
when possible.) 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 Tue May 7 12:53:02 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:53:02 +0000
Subject: [Bugs] [Bug 1707393] Refactor dht lookup code
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707393
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22676
--
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 May 7 12:53:03 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 12:53:03 +0000
Subject: [Bugs] [Bug 1707393] Refactor dht lookup code
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1707393
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #1 from Worker Ant ---
REVIEW: https://review.gluster.org/22676 (cluster/dht: refactor dht lookup
functions) posted (#1) for review on release-6 by N Balachandran
--
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 May 7 13:40:15 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:40:15 +0000
Subject: [Bugs] [Bug 902955] [enhancement] Provide a clear and easy way to
integrate 3rd party translators
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=902955
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed|2017-03-08 10:49:06 |2019-05-07 13:40:15
--- Comment #7 from Amar Tumballi ---
Joe, while this has been a valid request, we couldn't get to implement this
with GD1 (and later tried it with GD2 as template based volgen). With current
scope of things, we are not considering it at the moment.
Closing it as DEFERRED, so we can revisit at these after couple of more
releases, depending on the capacity.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 13:48:08 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:48:08 +0000
Subject: [Bugs] [Bug 1032382] autogen.sh warnings with automake-1.14
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1032382
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 6306
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 13:48:10 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:48:10 +0000
Subject: [Bugs] [Bug 1032382] autogen.sh warnings with automake-1.14
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1032382
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #5 from Worker Ant ---
REVIEW: https://review.gluster.org/6306 (Set subdir-objects automake option in
configure.ac) posted (#2) 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 Tue May 7 13:49:43 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:49:43 +0000
Subject: [Bugs] [Bug 1037511] Operation not permitted occurred during
setattr of
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1037511
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 13:49:43
--- Comment #11 from Amar Tumballi ---
Not heard of this issue in sometime. Regret that it was open for a long time,
and apologize for the same. But we are not 'concentrating' on Quota feature at
the moment, and hence marking bug as DEFERRED. Will reopen if we get cycles to
look into after couple of releases. Please raise the concern in mailing list if
this is concerning.
Meantime, we request to upgrade to glusterfs-6.x releases to utilize some
stability improvements over the years.
--
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 May 7 13:51:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:51:06 +0000
Subject: [Bugs] [Bug 1065634] Enabling compression and encryption
translators on the same volume causes data corruption
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1065634
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |WONTFIX
Last Closed| |2019-05-07 13:51:06
--- Comment #7 from Amar Tumballi ---
The feature is now deprecated from glusterfs-6.0 release. We will not be taking
any work on this area for now.
If this is a critical feature for you, please feel free to raise the issue in
github or mailing list.
--
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 May 7 13:57:54 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:57:54 +0000
Subject: [Bugs] [Bug 1131447] [Dist-geo-rep] : Session folders does not sync
after a peer probe to new node.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1131447
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |WORKSFORME
Last Closed| |2019-05-07 13:57:54
--- Comment #4 from Amar Tumballi ---
Have not heard about this in a long time. Will be closing it as WORKSFORME. If
anyone finds the issue feel free to reopen. I recommend upgrading to
glusterfs-6.x releases or above for trying out these things.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 13:59:33 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 13:59:33 +0000
Subject: [Bugs] [Bug 1155181] Lots of compilation warnings on OSX. We should
probably fix them.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1155181
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |EasyFix
Priority|medium |low
Severity|medium |low
--- Comment #23 from Amar Tumballi ---
Good for someone new to GlusterFS to pick this and fix it. Keeping this open.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:00:46 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:00:46 +0000
Subject: [Bugs] [Bug 1158051] [USS]: files/directories with the name of
entry-point directory present in the snapshots cannot be accessed
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1158051
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |WONTFIX
Last Closed| |2019-05-07 14:00:46
--- Comment #1 from Amar Tumballi ---
While this is a valid case, we are not interested to fix it, and rather call it
as a intended behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:00:47 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:00:47 +0000
Subject: [Bugs] [Bug 1160678] [USS]: In Fuse files/directories with the name
of entry-point directory present in the snapshots cannot be accessed
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1160678
Bug 1160678 depends on bug 1158051, which changed state.
Bug 1158051 Summary: [USS]: files/directories with the name of entry-point directory present in the snapshots cannot be accessed
https://bugzilla.redhat.com/show_bug.cgi?id=1158051
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |WONTFIX
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:22:29 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:22:29 +0000
Subject: [Bugs] [Bug 1158130] Not possible to disable fopen-keeo-cache when
mounting
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1158130
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |low
CC| |atumball at redhat.com
Assignee|vbellur at redhat.com |atumball at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:26:29 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:26:29 +0000
Subject: [Bugs] [Bug 1158130] Not possible to disable fopen-keeo-cache when
mounting
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1158130
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
External Bug ID| |Gluster.org Gerrit 22678
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:26:31 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:26:31 +0000
Subject: [Bugs] [Bug 1158130] Not possible to disable fopen-keeo-cache when
mounting
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1158130
Worker Ant changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |POST
--- Comment #2 from Worker Ant ---
REVIEW: https://review.gluster.org/22678 (mount.glusterfs: make
fcache-keep-open option take a value) 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 Tue May 7 14:32:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:32:12 +0000
Subject: [Bugs] [Bug 1179179] When an unsupported AUTH_* scheme is used,
the RPC-Reply should contain MSG_DENIED/AUTH_ERROR/AUTH_FAILED
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1179179
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 14:32:12
--- Comment #5 from Amar Tumballi ---
With the focus of the project not containing gNFS related improvements, marking
it as DEFERRED for now. We will look into this after couple of releases to take
stock of things. Please send an email to mailing list if you find this
critical.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:35:17 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:35:17 +0000
Subject: [Bugs] [Bug 1183054] rpmlint throws couple of errors for RPM spec
file
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1183054
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|high |medium
CC| |atumball at redhat.com,
| |kkeithle at redhat.com,
| |ndevos at redhat.com,
| |rkothiya at redhat.com
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:40:37 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:40:37 +0000
Subject: [Bugs] [Bug 1187347] RPC ping does not retransmit
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1187347
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 14:40:37
--- Comment #2 from Amar Tumballi ---
Hi Scott, thanks for your detailed report. We regret keeping it open for such a
long time. Currently we recommend you to upgrade to glusterfs-6.x and see if
the behavior is fine for you. With the current scope of things, we can't pick
this bug to work on (as there are options for having backup-volfile-server
etc).
Will keep this bug under DEFERRED status, we will revisit this after couple of
releases. We also are looking at implementing a different n/w layer based
solution (ref: https://github.com/gluster/glusterfs/issues/391 &
https://github.com/gluster/glusterfs/issues/505). Feel free to follow those
issues to keep track of the progress.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:48:50 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:48:50 +0000
Subject: [Bugs] [Bug 1196028] libgfapi: glfs_init() hangs on
pthread_cond_wait() when user is non-root
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1196028
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |WORKSFORME
Last Closed| |2019-05-07 14:48:50
--- Comment #4 from Amar Tumballi ---
Tried glfsxmp.c as a non-user, and things are working fine with glusterfs-6.x
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 14:59:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 14:59:06 +0000
Subject: [Bugs] [Bug 1214671] Diagnosis and recommended fix to be added in
glusterd-messages.h
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1214671
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 14:59:06
--- Comment #4 from Amar Tumballi ---
While this is a valid ask, we can't pick this up till we look into structured
logging improvements, which we would pickup before this. So keeping the effort
as DEFERRED with current scope, please raise issues through email
(Mailinglist), if there are concerns. We will revisit the issue after couple of
releases to take a stand.
--
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 May 7 15:14:06 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 15:14:06 +0000
Subject: [Bugs] [Bug 1215017] gf_msg not giving output to STDOUT.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1215017
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |WONTFIX
Last Closed| |2019-05-07 15:14:06
--- Comment #3 from Amar Tumballi ---
Not planning to change gf_log() to gf_msg() before daemonizing the process.
Hence marking as WONTFIX.
--
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 May 7 15:22:27 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 15:22:27 +0000
Subject: [Bugs] [Bug 1215022] Populate message IDs with recommended action.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1215022
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |CURRENTRELEASE
Flags|needinfo?(hchiramm at redhat.c |
|om) |
Last Closed| |2019-05-07 15:22:27
--- Comment #4 from Amar Tumballi ---
> So should we open a more specific issue and close this one?
I am inclined towards closing this bug, and open new bugs to track specific
efforts.
Closing with CURRENTRELEASE, and will open any particular bugs per components
so we can track them to future releases.
--
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 May 7 15:25:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 15:25:13 +0000
Subject: [Bugs] [Bug 1215129] After adding/removing the bricks to the volume,
bitrot is crawling bricks of other bitrot enabled volumes.
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1215129
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |WORKSFORME
Assignee|bugs at gluster.org |rabhat at redhat.com
Last Closed| |2019-05-07 15:25:13
--- Comment #8 from Amar Tumballi ---
This is not seen in latest releases (glusterfs-6.x). Please reopen if seen
again.
--
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 May 7 15:26:54 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 15:26:54 +0000
Subject: [Bugs] [Bug 1217372] Disperse volume: NFS client mount point hung
after the bricks came back up
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1217372
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 15:26:54
--- Comment #3 from Amar Tumballi ---
As of glusterfs-6.x have not heard of this issue. Considering we haven't run a
test to validate this, marking it as DEFERRED for now, and revisiting this
after couple of releases.
If you find the issue is happening still with glusterfs-6.x releases, feel free
to re-open it.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 21:05:17 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 21:05:17 +0000
Subject: [Bugs] [Bug 1221980] bitd log grows rapidly if brick goes down
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1221980
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|unspecified |low
Status|NEW |CLOSED
CC| |atumball at redhat.com
Assignee|bugs at gluster.org |rabhat at redhat.com
Resolution|--- |WORKSFORME
Fixed In Version| |glusterfs-6.x
Severity|unspecified |low
Last Closed| |2019-05-07 21:05:17
--- Comment #4 from Amar Tumballi ---
Not seeing with latest glusterfs-6.x releases. Please reopen if seen.
--
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 May 7 21:06:13 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 21:06:13 +0000
Subject: [Bugs] [Bug 1231171] [RFE]- How to find total number of glusterfs
client mounts?
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1231171
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |CURRENTRELEASE
Last Closed|2018-10-07 13:32:54 |2019-05-07 21:06:13
--
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 May 7 21:10:36 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 21:10:36 +0000
Subject: [Bugs] [Bug 1246024] gluster commands space in brick path fails
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1246024
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |DEFERRED
Last Closed| |2019-05-07 21:10:36
--- Comment #2 from Amar Tumballi ---
This remains as a bug, but fixing this currently is not a priority among other
things. It would become a major work, as everywhere we take brick as argument,
we need to handle space.
We will add this in documentation, and mark this bug as DEFERRED, so we can
revisit this after couple of releases.
--
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 May 7 21:14:12 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 21:14:12 +0000
Subject: [Bugs] [Bug 1251614] gf_defrag_fix_layout recursively fails,
distracting from the root cause
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1251614
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Fixed In Version| |glusterfs-6.x
Resolution|--- |WORKSFORME
Last Closed| |2019-05-07 21:14:12
--- Comment #1 from Amar Tumballi ---
With introduction of commit-hash and other things in rebalance, this looks more
fool proof, and didn't see any issues in latest codebase. Will mark it as
WORKSFORME (with glusterfs-6.x) release. If the issue persists, will take it up
in one of the future releases.
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at redhat.com Tue May 7 21:23:04 2019
From: bugzilla at redhat.com (bugzilla at redhat.com)
Date: Tue, 07 May 2019 21:23:04 +0000
Subject: [Bugs] [Bug 1255582] Add the ability to force an unconditional
graph reload
In-Reply-To:
References:
Message-ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1255582
Amar Tumballi changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
CC| |atumball at redhat.com
Resolution|--- |WONTFIX
Last Closed| |2019-05-07 21:23:04
--- Comment #1 from Amar Tumballi