glusterfs.git/glusterfsd/src, branch v3.10.4

glusterfsd: send PARENT_UP on brick attach

2017-05-31T05:59:07+00:00

With brick multiplexing being enabled, if a brick is instance attached to a
process then a PARENT_UP event is needed so that it reaches right till
posix layer and then from posix CHILD_UP event is sent back to all the
children.

>Reviewed-on: https://review.gluster.org/17225
>NetBSD-regression: NetBSD Build System 
>Smoke: Gluster Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Jeff Darcy 
>(cherry picked from commit 86ad032949cb80b6ba3df9dc8268243529d4eb84)

Change-Id: Ic341086adb3bbbde0342af518e1b273dd2f669b9
BUG: 1450728
Signed-off-by: Atin Mukherjee 
Reviewed-on: https://review.gluster.org/17288
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

rpc: avoid logging success on failure

2017-05-31T05:57:16+00:00

Avoid logging Success in the event of failure especially when errno
has no meaningful value w.r.t. the failure. In this case the errno 
is set to zero when there's indeed a failure at the RPC level.

mainline:
> BUG: 1426032
> Signed-off-by: Milind Changire 
> Reviewed-on: https://review.gluster.org/16730
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: N Balachandran 
> Reviewed-by: Jeff Darcy 
(cherry picked from commit 89c6bedc1c2e978f67ca29f212a357984cd8a2dd)

Change-Id: If2cc81aa1e590023ed22892dacbef7cac213e591
BUG: 1451995
Signed-off-by: Milind Changire 
Reviewed-on: https://review.gluster.org/17326
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Talur

glusterd: cleanup pidfile on pmap signout

2017-05-10T10:42:07+00:00

This patch ensures
1. brick pidfile is cleaned up on pmap signout
2. pmap signout evemt is sent for all the bricks when a brick process
shuts down.

>Reviewed-on: https://review.gluster.org/17168
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Jeff Darcy 
>(cherry picked from commit 3d35e21ffb15713237116d85711e9cd1dda1688a)

Change-Id: I7606a60775b484651d4b9743b6037b40323931a2
BUG: 1449002
Signed-off-by: Atin Mukherjee 
Reviewed-on: https://review.gluster.org/17209
Smoke: Gluster Build System 
Reviewed-by: Prashanth Pai 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

glusterd: socketfile & pidfile related fixes for brick multiplexing feature

2017-05-10T10:42:05+00:00

Problem: While brick-muliplexing is on after restarting glusterd, CLI is
         not showing pid of all brick processes in all volumes.

Solution: While brick-mux is on all local brick process communicated through one
          UNIX socket but as per current code (glusterd_brick_start) it is trying
          to communicate with separate UNIX socket for each volume which is populated
          based on brick-name and vol-name.Because of multiplexing design only one
          UNIX socket is opened so it is throwing poller error and not able to
          fetch correct status of brick process through cli process.
          To resolve the problem write a new function glusterd_set_socket_filepath_for_mux
          that will call by glusterd_brick_start to validate about the existence of socketpath.
          To avoid the continuous EPOLLERR erros in  logs update socket_connect code.

Test:     To reproduce the issue followed below steps
          1) Create two distributed volumes(dist1 and dist2)
          2) Set cluster.brick-multiplex is on
          3) kill glusterd
          4) run command gluster v status
          After apply the patch it shows correct pid for all volumes

> BUG: 1444596
> Change-Id: I5d10af69dea0d0ca19511f43870f34295a54a4d2
> Signed-off-by: Mohit Agrawal 
> Reviewed-on: https://review.gluster.org/17101
> Smoke: Gluster Build System 
> Reviewed-by: Prashanth Pai 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Atin Mukherjee 
> (cherry picked from commit 21c7f7baccfaf644805e63682e5a7d2a9864a1e6)

Change-Id: I1892c80b9ffa93974f20c92d421660bcf93c4cda
BUG: 1449002
Signed-off-by: Mohit Agrawal 
Reviewed-on: https://review.gluster.org/17210
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Prashanth Pai

glusterfsd+libglusterfs: add null checks during attach

2017-03-10T19:51:13+00:00

It's possible (though unlikely) that we could get a brick-attach
request while we're not ready to process it (ctx->active not set yet).
Add code to guard against this possibility, and return appropriate
error indicators.

Backport of:
> 90b2b9b29f552fe9ab53de5c4123003522399e6d
> BUG: 1430860
> Reviewed-on: https://review.gluster.org/16883

Change-Id: Icb3bc52ce749258a3f03cbbbdf4c2320c5c541a0
BUG: 1422769
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16888
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

glusterfsd: don't quit (in client) on connection failure

2017-03-10T19:49:13+00:00

Backport of:
> eb038c19e2c799e35e72eeb500dfb81efc5567e2
> BUG: 1430042
> Reviewed-on: https://review.gluster.org/16866

Change-Id: I32be91e9db361a45454d6340a4c4ac2d0d7efffc
BUG: 1422781
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16886
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

core: Clean up pmap registry up correctly on volume/brick stop

2017-02-28T15:29:54+00:00

This commit changes the following:
1. In glusterfs_handle_terminate, send out individual pmap signout
requests to glusterd for every brick.
2. Add another parameter to glusterfs_mgmt_pmap_signout function to
pass the brickname that needs to be removed from the pmap registry.
3. Make sure pmap_registry_search doesn't break out from the loop
iterating over the list of bricks per port if the first brick entry
corresponding to a port is whitespaced out.
4. Make sure the pmap registry entries are removed for other
daemons like snapd.

> Reviewed-on: https://review.gluster.org/16689
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Gaurav Yadav 
> Reviewed-by: Jeff Darcy 

(cherry picked from commit 1e3538baab7abc29ac329c78182b62558da56d98)

Change-Id: I69949874435b02699e5708dab811777ccb297174
BUG: 1427461
Signed-off-by: Samikshan Bairagya 
Reviewed-on: https://review.gluster.org/16786
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

glusterd: add a cli command to trigger a statedump on a client

2017-02-14T01:53:10+00:00

With this, we will be able to trigger statedumps on remote Gluster
clients, mainly targetted for applications using libgfapi.

Design:
SIGUSR signal is the most comman way of taking a statedump in Gluster.
But it cannot be used for libgfapi based processes, as the process
loading the library might have already consumed SIGUSR signal. Hence
going by the command way.

One has to issue a Gluster command to initiate a statedump on the
libgfapi based client. The command takes hostname and PID as an
argument. All the glusterds in the cluster, check if they are connected
to the specified hostname, and send an RPC request to all the connected
clients from that hostname (via the mgmt connection).

> URL: http://review.gluster.org/16357
> BUG: 1169302
> Signed-off-by: Poornima G 
> [ndevos: minor fixes and split patch in smaller pieces]
> Reviewed-on-master: https://review.gluster.org/9228
> Reviewed-by: Niels de Vos 
> Tested-by: Niels de Vos 
> Reviewed-by: Kaleb KEITHLEY 
> Reviewed-by: Samikshan Bairagya 

BUG: 1418981
Change-Id: Icbe4d2f026b32a2c7d5535e1bfb2cdaaff042e91
Signed-off-by: Shyam 
Reviewed-on: https://review.gluster.org/16601
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

glusterfsd/gf_attach: Remove unused varibale

2017-02-03T19:55:12+00:00

>Change-Id: I1f2ae36c91bd0880a7f15aa73b7e0f462c7e7952
>BUG: 1198849
>Signed-off-by: Anoop C S 
>Reviewed-on: https://review.gluster.org/16517
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>Reviewed-by: Jeff Darcy 
>CentOS-regression: Gluster Build System 

(cherry picked from commit b0012f81089258dc0b864db4b34afc3205c265df)

Change-Id: I1f2ae36c91bd0880a7f15aa73b7e0f462c7e7952
Signed-off-by: Anoop C S 
Reviewed-on: https://review.gluster.org/16538
Smoke: Gluster Build System 
Reviewed-by: Jeff Darcy 
Tested-by: Jeff Darcy 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

libglusterfs: make memory pools more thread-friendly

2017-02-03T00:44:09+00:00

Early multiplexing tests revealed *massive* contention on certain
pools' global locks - especially for dictionaries and secondarily for
call stubs.  For the thread counts that multiplexing can create, a
more lock-free solution is clearly needed.  Also, the current mem-pool
implementation does a poor job releasing memory back to the system,
artificially inflating memory usage to match whatever the worst case
was since the process started.  This is bad in general, but especially
so for multiplexing where there are more pools and a major point of
the whole exercise is to reduce memory consumption.

The basic ideas for the new design are these

  There is one pool, globally, for each power-of-two size range.
  Every attempt to create a new pool within this range will instead
  add a reference to the existing pool.

  Instead of adding pools for each translator within each multiplexed
  brick (potentially infinite and quite possibly thousands), we
  allocate one set of size-based pools per *thread* (hundreds at
  worst).

  Each per-thread pool is divided into hot and cold lists.  Every
  allocation first attempts to use the hot list, then the cold list.
  When objects are freed, they always go on the hot list.

  There is one global "pool sweeper" thread, which periodically
  reclaims everything in each pool's cold list and then "demotes" the
  current hot list to be the new cold list.

  For normal allocation activity, only a per-thread lock need be
  taken, and even that only to guard against very rare contention from
  the pool sweeper.  When threads start and stop, a global lock must
  be taken to add them to the pool sweeper's list.  Lock contention is
  therefore extremely low, and the hot/cold lists also provide good
  locality.

A more complete explanation (of a similar earlier design) can be found
here:

 http://www.gluster.org/pipermail/gluster-devel/2016-October/051160.html

Backport of:
> Change-Id: I5bc8a1ba57cfb553998f979a498886e0d006e665
> BUG: 1385758
> Reviewed-on: https://review.gluster.org/15645

BUG: 1418091
Change-Id: Id09bbea41f65fcd245822607bc204f3a34904dc2
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16531
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan