glusterfs.git/xlators/mgmt/glusterd/src/glusterd-pmap.c, branch v3.9.0rc2

glusterd: Add async events

2016-08-22T13:10:44+00:00

As the eventing framework is already in the code, this patch targets to capture
all the async glusterd events which are important to be notified to the higher
layers which consume the eventing framework.

I plan to break this work into two different patches where this patch set covers
the first set of events.

Change-Id: Ie1bd4f6fa84117b26ccb4c75bc4dc68e6ef19134
BUG: 1360809
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/15015
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Rohan Kanade 
Reviewed-by: Samikshan Bairagya

glusterd: clean up old port and allocate new one on every restart

2016-08-04T04:43:34+00:00

GlusterD as of now was blindly assuming that the brick port which was already
allocated would be available to be reused and that assumption is absolutely
wrong.

Solution : On first attempt, we thought GlusterD should check if the already
allocated brick ports are free, if not allocate new port and pass it to the
daemon. But with that approach there is a possibility that if PMAP_SIGNOUT is
missed out, the stale port will be given back to the clients where connection
will keep on failing. Now given the port allocation always start from base_port,
if everytime a new port has to be allocated for the daemons, the port range will
still be under control. So this fix tries to clean up old port using
pmap_registry_remove () if any and then goes for pmap_registry_alloc ()

Change-Id: If54a055d01ab0cbc06589dc1191d8fc52eb2c84f
BUG: 1221623
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/15005
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Avra Sengupta

glusterd: search for free port from base_port

2016-07-18T12:55:58+00:00

When a volume is deleted, the freed up ports are never considered for further
allocation since pmap_registry_alloc () always starts scanning from last_alloc.
So in use cases where gluster volumes are frequently created and deleted
managing ports become nightmare as for every new volume creation ports need to
be opened up by the admin based on the volume topology.

Solution: Instead of scanning from last_alloc, pmap_registry_alloc () always
starts from base_port now. What that means is glusterd will always try to find
out the ports which have been freed from earlier volumes and reallocate them for
the newer ones. There could be possibilities that when a volume is stopped and
started back their brick ports are changed which is completely acceptible IMHO.

Change-Id: I99ccc11732b6a75527fcb6abafaf249ed02b3b78
BUG: 1221623
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/14939
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Jeff Darcy 
Smoke: Gluster Build System

mgmt: remove unused and misleading pmap_signup

2016-07-08T04:26:26+00:00

We use signin, but not signup.  Having both just introduces confusion.
The proc number has been retained to avoid changes to the numbering of
other procs, and the mapping to a name has similarly been retained as a
placeholder, but the code and structure definitions have been removed.

Change-Id: I60f64f3b5d71ba6ed6862b36a38f90a9c8271c9f
Signed-off-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/14792
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

glusterd: search port from last_alloc to base_port

2016-07-05T11:43:21+00:00

If a brick process is killed ungracefully then GlusterD wouldn't receive a
PMAP_SIGNOUT event and hence the stale port details wouldn't be removed out.

Now consider the following case:
1. Create a volume with 1 birck
2. Start the volume (say brick port allocated is 49152)
3. Kill the brick process by 'kill -9'
4. Stop & delete the volume
5. Recreate the volume and start it. (Now the brick port gets 49153)
6. Mount the volume

Now in step 6 mount will fail as GlusterD will provide back the stale port
number given the query starts searching from the base_port.

Solution:

To avoid this, searching for port from last_alloc and coming down to base_port
should solve the issue.

Change-Id: I9afafd722a7fda0caac4cc892605f4e7c0e48e73
BUG: 1334270
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/14268
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Samikshan Bairagya 
Reviewed-by: Jeff Darcy

glusterd: compare uuid instead of hostname address resolution

2016-07-05T07:23:35+00:00

In glusterd_get_brickinfo () brick's hostname is address resolved. This adds an
unnecessary latency since it uses calls like getaddrinfo (). Instead given the
local brick's uuid is already known a comparison of MY_UUID and brickinfo->uuid
is much more light weight than the previous approach.

On a scale testing where cluster hosting ~400 volumes spanning across 4 nodes,
if a node goes for a reboot, few of the bricks don't come up. After few days of
analysis its found that glusterd_pmap_sigin () was taking signficant amount of
latency and further code walthrough revealed this unnecessary address
resolution. Applying this fix solves the issue and now all the brick processes
come up on a node reboot.

Change-Id: I299b8660ce0da6f3f739354f5c637bc356d82133
BUG: 1352279
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/14849
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Prashanth Pai 
Reviewed-by: Samikshan Bairagya 
Reviewed-by: Kaushal M

glusterd: fix max pmap alloc to GF_PORT_MAX

2016-04-29T05:29:11+00:00

This patch also mops the port max i.e 65535 hard coding

Change-Id: Ia93656d75ceb4c6c4849f9e0ad1b260d5952d4c6
BUG: 1331253
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/14096
Tested-by: Prasanna Kumar Kalever 
Smoke: Gluster Build System 
Reviewed-by: Atin Mukherjee 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

glusterd: try to connect on GF_PMAP_PORT_FOREIGN aswell

2016-04-28T04:35:27+00:00

This patch fix couple of things mentioned below:

1. previously we use to try to connect on only GF_PMAP_PORT_FREE
in the pmap_registry_alloc(), it could happen that some foreign process
would have freed the port by this time ?, hence it is worth giving a try on
GF_PMAP_PORT_FOREIGN ports as well instead of wasting them all.

2. fix pmap_registry_remove() to mark the port asGF_PMAP_PORT_FREE

3. added useful comments on gf_pmap_port_type enum members

Change-Id: Id2aa7ad55e76ae3fdece21bed15792525ae33fe1
BUG: 1322805
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/14080
Tested-by: Prasanna Kumar Kalever 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee

glusterd: scan for open ports only in required range

2016-03-30T19:44:23+00:00

It does not make sense to keep track of free ports from 0 to base_port
if we are not going to use them.

glusterd start times without this patch
2.622
2.478
2.455
2.590
2.400

glusterd start times with this patch
1.9
1.9
1.9
2.0
2.0
1.8

We save around half a second for every glusterd start.

BUG: 1322237
Change-Id: I0456689d0afad50dd068f2325ebfca9bdeffe01a
Signed-off-by: Raghavendra Talur 
Reviewed-on: http://review.gluster.org/13841
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Jeff Darcy

core: use syscall wrappers instead of direct syscalls -- glusterd

2015-10-28T13:55:04+00:00

various xlators and other components are invoking system calls
directly instead of using the libglusterfs/syscall.[ch] wrappers.

If not using the system call wrappers there should be a comment
in the source explaining why the wrapper isn't used.

Change-Id: I28bf2a5f7730b35914e7ab57fed91e1966b30073
BUG: 1267967
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/12379
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy