<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glusterfs.git/glusterfsd/src, branch v3.7.2</title>
<subtitle></subtitle>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/'/>
<entry>
<title>libglusterfs: Enabling the fini()  in cleanup_and_exit()</title>
<updated>2015-06-17T04:15:11+00:00</updated>
<author>
<name>anand</name>
<email>anekkunt@redhat.com</email>
</author>
<published>2015-05-22T12:48:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=6724ae3b3becdf6be495e8b4f81f1fba302da69e'/>
<id>6724ae3b3becdf6be495e8b4f81f1fba302da69e</id>
<content type='text'>
Problem 1 : glusterd was crashing due to race between clean up thread and rpc event thread.

Scenario:
As we can observed, X thread is in the process of exiting the process. It has already
run the exit handlers, which cleanup things that require cleaning up. This includes
liburcu resources. By the time Y thread  called rcu_bp_register(), the liburcu resources
have been cleaned up. rcu_bp_register() tries to access these non-existent resources,
which leads to the segmentation fault.

Note1:
Crash happen when the process is almost at the point of stopping(exiting), it doesn't have any
serious impact to functionality apart from creating the core dump file and the log message.

Fix .Do proper clean up before calling exit().

Note2: Other xlator have clean up issues,so only glusterd clean up function invoked.

Note3: This patch also solve the selinux issue.

Problem 2 : glusterd runs as rpm_script_t when it's executed from the rpm scriptlet,files created
in this context are set as rpm_script_t, so glusterd unable to access these files when it runs
in glusterd_t context.

Fix: Fini clean up the files while glusterd exiting, so files are recreated by glusterd while
starting with proper SElinux context label.

Backport of :
&gt;Change-Id: Idcfd087f51c18a729bdf44a146f9d294e2fca5e2
&gt;BUG: 1209461
&gt;Signed-off-by: anand &lt;anekkunt@redhat.com&gt;
&gt;Reviewed-on: http://review.gluster.org/10894
&gt;Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
&gt;Reviewed-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
&gt;Tested-by: NetBSD Build System &lt;jenkins@build.gluster.org&gt;
&gt;Reviewed-by: Raghavendra Bhat &lt;raghavendra@redhat.com&gt;
&gt;Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;

Change-Id: I59579e675bd73d7a19f7b965bd2c3c0fcd95d241
BUG: 1230026
Signed-off-by: anand &lt;anekkunt@redhat.com&gt;
Reviewed-on: http://review.gluster.org/11155
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Tested-by: NetBSD Build System &lt;jenkins@build.gluster.org&gt;
Reviewed-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Problem 1 : glusterd was crashing due to race between clean up thread and rpc event thread.

Scenario:
As we can observed, X thread is in the process of exiting the process. It has already
run the exit handlers, which cleanup things that require cleaning up. This includes
liburcu resources. By the time Y thread  called rcu_bp_register(), the liburcu resources
have been cleaned up. rcu_bp_register() tries to access these non-existent resources,
which leads to the segmentation fault.

Note1:
Crash happen when the process is almost at the point of stopping(exiting), it doesn't have any
serious impact to functionality apart from creating the core dump file and the log message.

Fix .Do proper clean up before calling exit().

Note2: Other xlator have clean up issues,so only glusterd clean up function invoked.

Note3: This patch also solve the selinux issue.

Problem 2 : glusterd runs as rpm_script_t when it's executed from the rpm scriptlet,files created
in this context are set as rpm_script_t, so glusterd unable to access these files when it runs
in glusterd_t context.

Fix: Fini clean up the files while glusterd exiting, so files are recreated by glusterd while
starting with proper SElinux context label.

Backport of :
&gt;Change-Id: Idcfd087f51c18a729bdf44a146f9d294e2fca5e2
&gt;BUG: 1209461
&gt;Signed-off-by: anand &lt;anekkunt@redhat.com&gt;
&gt;Reviewed-on: http://review.gluster.org/10894
&gt;Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
&gt;Reviewed-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
&gt;Tested-by: NetBSD Build System &lt;jenkins@build.gluster.org&gt;
&gt;Reviewed-by: Raghavendra Bhat &lt;raghavendra@redhat.com&gt;
&gt;Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;

Change-Id: I59579e675bd73d7a19f7b965bd2c3c0fcd95d241
BUG: 1230026
Signed-off-by: anand &lt;anekkunt@redhat.com&gt;
Reviewed-on: http://review.gluster.org/11155
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Tested-by: NetBSD Build System &lt;jenkins@build.gluster.org&gt;
Reviewed-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>core: Global timer-wheel</title>
<updated>2015-05-10T12:27:40+00:00</updated>
<author>
<name>Venky Shankar</name>
<email>vshankar@redhat.com</email>
</author>
<published>2015-04-24T04:40:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=1a217b2a0295ca4d9068ee5c17d6a4374cc5f8fc'/>
<id>1a217b2a0295ca4d9068ee5c17d6a4374cc5f8fc</id>
<content type='text'>
Instantiate a process wide global instance of the timer wheel
data structure. Spawning glusterfs* process with option arg
"--global-timer-wheel" instantiates a global instance of
timer-wheel under global context (-&gt;ctx).

Translators can make use of this process wide instance [via a
call to glusterfs_global_timer_wheel()] instead of maintaining
an instance of their own and possibly consuming more memory.
Linux kernel too has a single instance of timer wheel where
subsystems such as IO, networking, etc.. make use of.

Bitrot daemon would be early consumers of this: bitrot translator
instances for multiple volumes would track objects belonging to
their respective bricks in this global expiry tracking data
structure. This is also a first step to move GlusterFS timer
mechanism to use timer-wheel.

&gt; Change-Id: Ie882df607e07acaced846ea269ebf1ece306d6ae
&gt; BUG: 1170075
&gt; Signed-off-by: Venky Shankar &lt;vshankar@redhat.com&gt;
&gt; Reviewed-on: http://review.gluster.org/10380
&gt; Tested-by: NetBSD Build System
&gt; Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
&gt; Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;

Change-Id: I35c840daa9996a059699f8ea5af54c76ede7e09c
Signed-off-by: Venky Shankar &lt;vshankar@redhat.com&gt;
Signed-off-by: Gaurav Kumar Garg &lt;ggarg@redhat.com&gt;
BUG: 1220041
Reviewed-on: http://review.gluster.org/10716
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Instantiate a process wide global instance of the timer wheel
data structure. Spawning glusterfs* process with option arg
"--global-timer-wheel" instantiates a global instance of
timer-wheel under global context (-&gt;ctx).

Translators can make use of this process wide instance [via a
call to glusterfs_global_timer_wheel()] instead of maintaining
an instance of their own and possibly consuming more memory.
Linux kernel too has a single instance of timer wheel where
subsystems such as IO, networking, etc.. make use of.

Bitrot daemon would be early consumers of this: bitrot translator
instances for multiple volumes would track objects belonging to
their respective bricks in this global expiry tracking data
structure. This is also a first step to move GlusterFS timer
mechanism to use timer-wheel.

&gt; Change-Id: Ie882df607e07acaced846ea269ebf1ece306d6ae
&gt; BUG: 1170075
&gt; Signed-off-by: Venky Shankar &lt;vshankar@redhat.com&gt;
&gt; Reviewed-on: http://review.gluster.org/10380
&gt; Tested-by: NetBSD Build System
&gt; Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
&gt; Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;

Change-Id: I35c840daa9996a059699f8ea5af54c76ede7e09c
Signed-off-by: Venky Shankar &lt;vshankar@redhat.com&gt;
Signed-off-by: Gaurav Kumar Garg &lt;ggarg@redhat.com&gt;
BUG: 1220041
Reviewed-on: http://review.gluster.org/10716
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>glusterd: gluster volume status should show status of bitrot and scrubber daemon</title>
<updated>2015-05-07T03:59:46+00:00</updated>
<author>
<name>Gaurav Kumar Garg</name>
<email>ggarg@redhat.com</email>
</author>
<published>2015-04-09T10:06:20+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=2d919eab43dfbcfbaa2617b161f3f4bdd1381e96'/>
<id>2d919eab43dfbcfbaa2617b161f3f4bdd1381e96</id>
<content type='text'>
Command gluster volume status &lt;VOLNAME&gt; should show the status of bitrot
and scrubber daemon and its pid information.

Along with displaying bitrot and scrubber daemon information in gluster
volume status command there should be command to show its individual status
separately.
Command to show individual status of bitrot and scrubber daemon will
following.

command to show only bitd daemon information will be
gluster volume status &lt;VOLNAME&gt; bitd

command to show only scrubber daemon information
gluster volume status &lt;VOLNAME&gt; scrub

Change-Id: Id86aae1156c8c599347c98e2a538f294d37376e4
BUG: 1218123
Signed-off-by: Gaurav Kumar Garg &lt;ggarg@redhat.com&gt;
Reviewed-on: http://review.gluster.org/10175
Reviewed-by: Kaushal M &lt;kaushal@redhat.com&gt;
Tested-by: Kaushal M &lt;kaushal@redhat.com&gt;
(cherry picked from commit da1416051d19d612d131acfde8589bc8658979b5)
Reviewed-on: http://review.gluster.org/10519
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Command gluster volume status &lt;VOLNAME&gt; should show the status of bitrot
and scrubber daemon and its pid information.

Along with displaying bitrot and scrubber daemon information in gluster
volume status command there should be command to show its individual status
separately.
Command to show individual status of bitrot and scrubber daemon will
following.

command to show only bitd daemon information will be
gluster volume status &lt;VOLNAME&gt; bitd

command to show only scrubber daemon information
gluster volume status &lt;VOLNAME&gt; scrub

Change-Id: Id86aae1156c8c599347c98e2a538f294d37376e4
BUG: 1218123
Signed-off-by: Gaurav Kumar Garg &lt;ggarg@redhat.com&gt;
Reviewed-on: http://review.gluster.org/10175
Reviewed-by: Kaushal M &lt;kaushal@redhat.com&gt;
Tested-by: Kaushal M &lt;kaushal@redhat.com&gt;
(cherry picked from commit da1416051d19d612d131acfde8589bc8658979b5)
Reviewed-on: http://review.gluster.org/10519
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>protocol: increase default group-cache-timeout to 300 seconds</title>
<updated>2015-05-06T17:34:22+00:00</updated>
<author>
<name>Niels de Vos</name>
<email>ndevos@redhat.com</email>
</author>
<published>2015-05-04T11:03:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=ae9a7bc41f127a6aad59e60c79709623a7c41e57'/>
<id>ae9a7bc41f127a6aad59e60c79709623a7c41e57</id>
<content type='text'>
sssd uses 300 seconds by default too. There is no need to overload sssd
with requests that it would have cached.

Cherry picked from commit 34833364e9839f0036bccd58ec0a8a963e69263e:
&gt; BUG: 1215187
&gt; Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
&gt; Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
&gt; Reviewed-on: http://review.gluster.org/10371
&gt; Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
&gt; Reviewed-by: Kaleb KEITHLEY &lt;kkeithle@redhat.com&gt;
&gt; Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;

Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
BUG: 1215189
Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-on: http://review.gluster.org/10523
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Tested-by: NetBSD Build System
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
sssd uses 300 seconds by default too. There is no need to overload sssd
with requests that it would have cached.

Cherry picked from commit 34833364e9839f0036bccd58ec0a8a963e69263e:
&gt; BUG: 1215187
&gt; Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
&gt; Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
&gt; Reviewed-on: http://review.gluster.org/10371
&gt; Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
&gt; Reviewed-by: Kaleb KEITHLEY &lt;kkeithle@redhat.com&gt;
&gt; Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;

Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
BUG: 1215189
Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-on: http://review.gluster.org/10523
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Tested-by: NetBSD Build System
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>glusterfsd: add "print-netgroups" and "print-exports" command</title>
<updated>2015-03-19T05:16:34+00:00</updated>
<author>
<name>Niels de Vos</name>
<email>ndevos@redhat.com</email>
</author>
<published>2015-01-01T12:15:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=a1755ee2765f3d1c9c26d51a49ad63d133932710'/>
<id>a1755ee2765f3d1c9c26d51a49ad63d133932710</id>
<content type='text'>
NFS now has the ability to use a separate file for "netgroups" and
"exports". An administrator should have the ability to check the
validity of the files before applying the configuration.

The "glusterfsd" command now has the following additional arguments that
can be used to check the configuration:

   --print-netgroups: Validate the netgroups file and print it out
   --print-exports: Validate the exports file and print it out

BUG: 1143880
Change-Id: I24c40d50110d49d8290f9fd916742f7e4d0df85f
URL: http://www.gluster.org/community/documentation/index.php/Features/Exports_Netgroups_Authentication
Original-author: Shreyas Siravara &lt;shreyas.siravara@gmail.com&gt;
CC: Richard Wareing &lt;rwareing@fb.com&gt;
CC: Jiffin Tony Thottan &lt;jthottan@redhat.com&gt;
Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9365
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
Tested-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NFS now has the ability to use a separate file for "netgroups" and
"exports". An administrator should have the ability to check the
validity of the files before applying the configuration.

The "glusterfsd" command now has the following additional arguments that
can be used to check the configuration:

   --print-netgroups: Validate the netgroups file and print it out
   --print-exports: Validate the exports file and print it out

BUG: 1143880
Change-Id: I24c40d50110d49d8290f9fd916742f7e4d0df85f
URL: http://www.gluster.org/community/documentation/index.php/Features/Exports_Netgroups_Authentication
Original-author: Shreyas Siravara &lt;shreyas.siravara@gmail.com&gt;
CC: Richard Wareing &lt;rwareing@fb.com&gt;
CC: Jiffin Tony Thottan &lt;jthottan@redhat.com&gt;
Signed-off-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9365
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
Tested-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>protocol/client: sequence CHILD_UP, CHILD_DOWN etc notifications</title>
<updated>2015-02-07T21:25:26+00:00</updated>
<author>
<name>Krishnan Parthasarathi</name>
<email>kparthas@redhat.com</email>
</author>
<published>2015-02-05T10:11:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=f18a3f30bbeaf3bb067b913082830d7f874555ca'/>
<id>f18a3f30bbeaf3bb067b913082830d7f874555ca</id>
<content type='text'>
... from all bricks in the volume

This patch is important in the context of MT epoll. With MT epoll,
notification events from client xlators could reach cluster xlators like
afr, dht, ec, stripe etc. in different orders.

For e.g, In a distributed replicate volume of 2 bricks, namely Brick1
and Brick2, the following network events are observed by a mount
process.

- connection to Brick1 is broken.
- connection to Brick1 has been restored.

- connection to Brick2 is broken.
- connection to Brick2 has been restored.

Without establishing a total ordering of events, we can't guarantee that
cluster xlators like afr, dht perceive them in the same order.  While we
would expect afr (say) to perceive it as only one of Brick1 and Brick2
going down at any given time, it is possible for the notification of
Brick2 going offline to race with the notification of Brick1 coming back
online.

Change-Id: I78f5a52bfb05593335d0e9ad53ebfff98995593d
BUG: 1104462
Signed-off-by: Krishnan Parthasarathi &lt;kparthas@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9591
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
... from all bricks in the volume

This patch is important in the context of MT epoll. With MT epoll,
notification events from client xlators could reach cluster xlators like
afr, dht, ec, stripe etc. in different orders.

For e.g, In a distributed replicate volume of 2 bricks, namely Brick1
and Brick2, the following network events are observed by a mount
process.

- connection to Brick1 is broken.
- connection to Brick1 has been restored.

- connection to Brick2 is broken.
- connection to Brick2 has been restored.

Without establishing a total ordering of events, we can't guarantee that
cluster xlators like afr, dht perceive them in the same order.  While we
would expect afr (say) to perceive it as only one of Brick1 and Brick2
going down at any given time, it is possible for the notification of
Brick2 going offline to race with the notification of Brick1 coming back
online.

Change-Id: I78f5a52bfb05593335d0e9ad53ebfff98995593d
BUG: 1104462
Signed-off-by: Krishnan Parthasarathi &lt;kparthas@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9591
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>epoll: Adding the ability to configure epoll threads</title>
<updated>2015-02-07T21:23:03+00:00</updated>
<author>
<name>Shyam</name>
<email>srangana@redhat.com</email>
</author>
<published>2015-01-26T19:20:31+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=a7f5893c9243c8c563db215352fa7e47f6968e8b'/>
<id>a7f5893c9243c8c563db215352fa7e47f6968e8b</id>
<content type='text'>
Add the ability to configure the number of event threads
for various gluster services.

Currently with the multi thread epoll patch, it is possible
to have more than one thread waiting on socket activity and
processing the same. This thread count is currently static,
which this commit makes dynamic.

The current services which use IO path, i.e brick processes,
any client process (nfs, FUSE, gfapi, heal,
rebalance, etc.a), gain 2 set parameters to control the number
of threads that are processing events. These settings are,
  - client.event-threads &lt;n&gt;
  - server.event-threads &lt;n&gt;

The client setting affects the client graph consumers, and the
server setting affects the brick processes. These are processed
and inited/reconfigured using the client/server protocol xlators.

Other services (say glusterd) would need to extend similar
configuration settings to take advantage of multi threaded event
processing.

At present glusterd is not enabled with this commit, as it does not
stand to gain from this multi-threading (as I understand it).

Change-Id: Id8422fc57a9f95a135158eb6477ccf9d3c9ea4d9
BUG: 1104462
Signed-off-by: Shyam &lt;srangana@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9488
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the ability to configure the number of event threads
for various gluster services.

Currently with the multi thread epoll patch, it is possible
to have more than one thread waiting on socket activity and
processing the same. This thread count is currently static,
which this commit makes dynamic.

The current services which use IO path, i.e brick processes,
any client process (nfs, FUSE, gfapi, heal,
rebalance, etc.a), gain 2 set parameters to control the number
of threads that are processing events. These settings are,
  - client.event-threads &lt;n&gt;
  - server.event-threads &lt;n&gt;

The client setting affects the client graph consumers, and the
server setting affects the brick processes. These are processed
and inited/reconfigured using the client/server protocol xlators.

Other services (say glusterd) would need to extend similar
configuration settings to take advantage of multi threaded event
processing.

At present glusterd is not enabled with this commit, as it does not
stand to gain from this multi-threading (as I understand it).

Change-Id: Id8422fc57a9f95a135158eb6477ccf9d3c9ea4d9
BUG: 1104462
Signed-off-by: Shyam &lt;srangana@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9488
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>uss: disable memory accounting for the snapshot daemon</title>
<updated>2015-01-28T14:05:24+00:00</updated>
<author>
<name>Raghavendra Bhat</name>
<email>raghavendra@redhat.com</email>
</author>
<published>2015-01-20T12:27:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=c8a6904396142b832ec31c37f43f44b139d24e1f'/>
<id>c8a6904396142b832ec31c37f43f44b139d24e1f</id>
<content type='text'>
* Bring in option to disable memory accounting for a glusterfs process
  This reverses the changes done by the commit
  7fba3a88f1ced610eca0c23516a1e720d75160cd.

* Change the key from "memory-accounting" to "no-memory-accounting", as by
  default all the glusterfs process enable memory accounting now. So to
  disable memory accounting for some process, "no-mem-accounting" argument has
  to be passed.

Change-Id: I39c7cefb0fe764ea3e48f4e73e1305b084c5f497
BUG: 1184366
Signed-off-by: Raghavendra Bhat &lt;raghavendra@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9469
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Bring in option to disable memory accounting for a glusterfs process
  This reverses the changes done by the commit
  7fba3a88f1ced610eca0c23516a1e720d75160cd.

* Change the key from "memory-accounting" to "no-memory-accounting", as by
  default all the glusterfs process enable memory accounting now. So to
  disable memory accounting for some process, "no-mem-accounting" argument has
  to be passed.

Change-Id: I39c7cefb0fe764ea3e48f4e73e1305b084c5f497
BUG: 1184366
Signed-off-by: Raghavendra Bhat &lt;raghavendra@redhat.com&gt;
Reviewed-on: http://review.gluster.org/9469
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>api, glusterfsd: Cleanup upon failure in glusterfs_ctx_defaults_init()</title>
<updated>2014-12-10T04:11:17+00:00</updated>
<author>
<name>Vijay Bellur</name>
<email>vbellur@redhat.com</email>
</author>
<published>2014-11-28T12:24:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=ecb58c9a3f716a87da7174c1aa721561b18ad27b'/>
<id>ecb58c9a3f716a87da7174c1aa721561b18ad27b</id>
<content type='text'>
This got introduced due to 656711d935000c16. Coverity
also picked this up as CIDs 1256176, 1256178, 1256180.

Signed-off-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
Change-Id: If12fa0075634383975846181917a2f9650f790e3
BUG: 789278
Reviewed-on: http://review.gluster.org/9213
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-by: Shyamsundar Ranganathan &lt;srangana@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This got introduced due to 656711d935000c16. Coverity
also picked this up as CIDs 1256176, 1256178, 1256180.

Signed-off-by: Vijay Bellur &lt;vbellur@redhat.com&gt;
Change-Id: If12fa0075634383975846181917a2f9650f790e3
BUG: 789278
Reviewed-on: http://review.gluster.org/9213
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Niels de Vos &lt;ndevos@redhat.com&gt;
Reviewed-by: Shyamsundar Ranganathan &lt;srangana@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rdma: client connection establishment takes more time</title>
<updated>2014-11-18T08:50:13+00:00</updated>
<author>
<name>Mohammed Rafi KC</name>
<email>rkavunga@redhat.com</email>
</author>
<published>2014-10-16T05:58:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.gluster.org/cgit/glusterfs.git/commit/?id=85e92d160bd71fdaeb3ae89d3440eec8fd438da9'/>
<id>85e92d160bd71fdaeb3ae89d3440eec8fd438da9</id>
<content type='text'>
For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume 
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: Ie8e3a7f532d4104829dbe995e99b35e95571466c
BUG: 1153569
Signed-off-by: Mohammed Rafi KC &lt;rkavunga@redhat.com&gt;
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Krishnan Parthasarathi &lt;kparthas@redhat.com&gt;
Reviewed-by: Raghavendra G &lt;rgowdapp@redhat.com&gt;
Tested-by: Raghavendra G &lt;rgowdapp@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume 
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: Ie8e3a7f532d4104829dbe995e99b35e95571466c
BUG: 1153569
Signed-off-by: Mohammed Rafi KC &lt;rkavunga@redhat.com&gt;
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System &lt;jenkins@build.gluster.com&gt;
Reviewed-by: Krishnan Parthasarathi &lt;kparthas@redhat.com&gt;
Reviewed-by: Raghavendra G &lt;rgowdapp@redhat.com&gt;
Tested-by: Raghavendra G &lt;rgowdapp@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
