glusterfs.git, branch v4.1.1 doc: Added release notes for 4.1.1 release 2018-06-25T15:33:40+00:00 ShyamsundarR srangana@redhat.com 2018-06-25T15:23:14+00:00 b17acca6d00b31a72bf8bcb81ab3bbb5787313c1 fixes: bz#1590442 Change-Id: I4144e79314a1ee927751946f26e7d79d337c819c Signed-off-by: ShyamsundarR <srangana@redhat.com> 
fixes: bz#1590442

Change-Id: I4144e79314a1ee927751946f26e7d79d337c819c
Signed-off-by: ShyamsundarR <srangana@redhat.com>
glusterfs: access trusted peer group via remote-host command 2018-06-25T13:39:52+00:00 Mohit Agrawal moagrawa@redhat.com 2018-06-20T10:43:00+00:00 17f9843a9a355b3d72422dd979b1491233aede34 Problem: In SSL environment the user is able to access volume via remote-host command without adding node in a trusted pool Solution: Change the list of rpc program in glusterd.c at the time of initialization while SSL is enabled > Change-Id: I987e433b639e68ad17b77b6452df1e22dbe0f199 > cherry picked from commit 234d611160840899bcfd5ab1c17a6253673d38ed BUG: 1593525 fixes: bz#1593525 Change-Id: Ice4eda3d8104a4d5641de3cffd7249e46080d48f Signed-off-by: Mohit Agrawal <moagrawa@redhat.com> 
Problem: In SSL environment the user is able to access volume
         via remote-host command without adding node in a trusted pool

Solution: Change the list of rpc program in glusterd.c at the
          time of initialization while SSL is enabled

> Change-Id: I987e433b639e68ad17b77b6452df1e22dbe0f199
> cherry picked from commit 234d611160840899bcfd5ab1c17a6253673d38ed

BUG: 1593525
fixes: bz#1593525
Change-Id: Ice4eda3d8104a4d5641de3cffd7249e46080d48f
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
gcron: create the lockfile if it is missing 2018-06-20T17:38:45+00:00 Niels de Vos ndevos@redhat.com 2018-06-12T07:51:44+00:00 acf0481bbf34e28d9aa850bd6c317b22bacae9bb The lockfile for the job may not exist yet. If that is the case, it should be created upon the first time it is accessed. Change-Id: I4da2b3ecdb79cc63ed82cc7bfa026c8f08d4d043 Fixes: bz#1590195 Signed-off-by: Niels de Vos <ndevos@redhat.com> (cherry picked from commit 7005b1a336e483ec150c2f924a618dcfe197db0b) 
The lockfile for the job may not exist yet. If that is the case, it
should be created upon the first time it is accessed.

Change-Id: I4da2b3ecdb79cc63ed82cc7bfa026c8f08d4d043
Fixes: bz#1590195
Signed-off-by: Niels de Vos <ndevos@redhat.com>
(cherry picked from commit 7005b1a336e483ec150c2f924a618dcfe197db0b)
gcron: catch OSError as well as IOError 2018-06-18T13:19:34+00:00 Niels de Vos ndevos@redhat.com 2018-06-12T07:49:09+00:00 45edc547a827c4e38b7ec82de6d96e77ca5e593f In case os.open() fails because the file does not exist, an OSError is raised. To prevent the script to abort uncleanly, catch the OSError in addition to the IOError. Change-Id: I48e5b23e17d63639cc33db51b4229249a9887880 Fixes: bz#1590195 Signed-off-by: Niels de Vos <ndevos@redhat.com> (cherry picked from commit 26b52694feb04c98e6c9436bcd4e23e1687f0237) 
In case os.open() fails because the file does not exist, an OSError is
raised. To prevent the script to abort uncleanly, catch the OSError in
addition to the IOError.

Change-Id: I48e5b23e17d63639cc33db51b4229249a9887880
Fixes: bz#1590195
Signed-off-by: Niels de Vos <ndevos@redhat.com>
(cherry picked from commit 26b52694feb04c98e6c9436bcd4e23e1687f0237)
storage/posix: Handle ENOSPC correctly in zero_fill 2018-06-14T08:39:42+00:00 Pranith Kumar K pkarampu@redhat.com 2018-06-13T06:47:28+00:00 67b2233055091fad6ad7d14c65e3bc12871bab82 Change-Id: Icc521d86cc510f88b67d334b346095713899087a fixes: bz#1591185 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> (cherry picked from commit 6ef91480f9e75f63100585bfd19694deb0c2457b) 
Change-Id: Icc521d86cc510f88b67d334b346095713899087a
fixes: bz#1591185
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
(cherry picked from commit 6ef91480f9e75f63100585bfd19694deb0c2457b)
doc: Updated final release notes for 4.1.0 2018-06-12T14:52:10+00:00 ShyamsundarR srangana@redhat.com 2018-06-12T14:50:43+00:00 b4f4480094b7c3ebda3319df0c3f96efd08b2176 Fixes: bz#1575386 Change-Id: Iad79e16d76a55a2c3fc46629f79fec677bad597f Signed-off-by: ShyamsundarR <srangana@redhat.com> 
Fixes: bz#1575386

Change-Id: Iad79e16d76a55a2c3fc46629f79fec677bad597f
Signed-off-by: ShyamsundarR <srangana@redhat.com>
protocol/server: Fix xdata leak in seek fop 2018-06-12T07:08:02+00:00 Pranith Kumar K pkarampu@redhat.com 2018-06-11T07:33:58+00:00 2cca9b4f1ca853c20be43213400f9a8803a71a7d Change-Id: I6125283ed22c04564f0b77bb7a50579a83e02eb0 fixes: bz#1590128 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> (cherry picked from commit fd5b48ea0afd907deb08604415bee14ab65f378b) 
Change-Id: I6125283ed22c04564f0b77bb7a50579a83e02eb0
fixes: bz#1590128
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
(cherry picked from commit fd5b48ea0afd907deb08604415bee14ab65f378b)
posix/ctime: Fix fops racing in updating mtime/atime 2018-06-08T12:56:57+00:00 Kotresh HR khiremat@redhat.com 2018-06-01T05:48:31+00:00 acd9a863e80a7f56e25b3ed151a4711126de3208 In distributed systems, there could be races with fops updating mtime/atime which could result in different mtime/atime for same file. So updating them only if time is greater than the existing makes sure, only the highest time is retained. If the mtime/atime update comes from the explicit utime syscall, it is allowed to set to previous time. Thanks Xavi for helping in rooting the issue. Backport of: > Patch: https://review.gluster.org/#/c/20120/ > BUG: 1584981 > Change-Id: If1230a75b96d7f9a828795189fcc699049e7826e > Signed-off-by: Kotresh HR <khiremat@redhat.com> (cherry picked from commit a6f0e7a4f1ca203762cae2ed5e426b52124c74dc) fixes: bz#1585894 Change-Id: If1230a75b96d7f9a828795189fcc699049e7826e Signed-off-by: Kotresh HR <khiremat@redhat.com> 
In distributed systems, there could be races with fops
updating mtime/atime which could result in different
mtime/atime for same file. So updating them only if
time is greater than the existing makes sure, only
the highest time is retained. If the mtime/atime
update comes from the explicit utime syscall, it is
allowed to set to previous time.

Thanks Xavi for helping in rooting the issue.

Backport of:
> Patch: https://review.gluster.org/#/c/20120/
> BUG: 1584981
> Change-Id: If1230a75b96d7f9a828795189fcc699049e7826e
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit a6f0e7a4f1ca203762cae2ed5e426b52124c74dc)


fixes: bz#1585894
Change-Id: If1230a75b96d7f9a828795189fcc699049e7826e
Signed-off-by: Kotresh HR <khiremat@redhat.com>
features/shard: Fix missing unlock in shard_fsync_shards_cbk() 2018-06-06T14:00:52+00:00 Vijay Bellur vbellur@redhat.com 2018-06-01T00:11:01+00:00 9757ee891cf45abd6380fd693639f5c4cd199c2f Backport of: > Change-Id: I745a98e957cf3c6ba69247fcf6b58dd05cf59c3c > Signed-off-by: Vijay Bellur <vbellur@redhat.com> > (cherry picked from commit b21f742f96d46b4adfa87281dd9a2e48fea8d031) > BUG: 789278 Change-Id: I745a98e957cf3c6ba69247fcf6b58dd05cf59c3c fixes: bz#1587908 Signed-off-by: Vijay Bellur <vbellur@redhat.com> (cherry picked from commit b21f742f96d46b4adfa87281dd9a2e48fea8d031) 
Backport of:
> Change-Id: I745a98e957cf3c6ba69247fcf6b58dd05cf59c3c
> Signed-off-by: Vijay Bellur <vbellur@redhat.com>
> (cherry picked from commit b21f742f96d46b4adfa87281dd9a2e48fea8d031)
> BUG: 789278

Change-Id: I745a98e957cf3c6ba69247fcf6b58dd05cf59c3c
fixes: bz#1587908
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
(cherry picked from commit b21f742f96d46b4adfa87281dd9a2e48fea8d031)
protocol/client: Don't send fops till SETVOLUME is complete 2018-05-31T20:29:45+00:00 Raghavendra G rgowdapp@redhat.com 2018-05-30T04:04:44+00:00 4f591e873c0a38b662910f8e8a5768fd3e9bbeaa An earlier commit set conf->connected just after rpc layer sends RPC_CLNT_CONNECT event. However, success of socket level connection connection doesn't indicate brick stack is ready to receive fops, as an handshake has to be done b/w client and server after RPC_CLNT_CONNECT event. Any fop sent to brick in the window between, * protocol/client receiving RPC_CLNT_CONNECT event * protocol/client receiving a successful setvolume response can end up accessing an uninitialized brick stack. So, set conf->connected only after a successful SETVOLUME. Change-Id: I139a03d2da6b0d95a0d68391fcf54b00e749decf fixes: bz#1584633 Signed-off-by: Raghavendra G <rgowdapp@redhat.com> (cherry picked from commit 430e4872db43447c8a15b638760d23c188257139) 
An earlier commit set conf->connected just after rpc layer sends
RPC_CLNT_CONNECT event. However, success of socket level connection
connection doesn't indicate brick stack is ready to receive fops, as
an handshake has to be done b/w client and server after
RPC_CLNT_CONNECT event. Any fop sent to brick in the window between,
* protocol/client receiving RPC_CLNT_CONNECT event
* protocol/client receiving a successful setvolume response

can end up accessing an uninitialized brick stack. So, set
conf->connected only after a successful SETVOLUME.

Change-Id: I139a03d2da6b0d95a0d68391fcf54b00e749decf
fixes: bz#1584633
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
(cherry picked from commit 430e4872db43447c8a15b638760d23c188257139)