glusterfs.git/libglusterfs, branch v3.10.2

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

core: fix synclocks' handling of "woken" flag

2017-04-13T15:39:09+00:00

The "woken" flag wasn't being reset when it should have been, leading
(eventually) to a SEGV when someone tried to folow a synclock's waitq
to a task structure that had been freed while still on the queue.  See
the bug report for (far) more detail.

Backport of:
> Commit 31377765dbbb8d49292c4362837a695adcbc6cb4
> BUG: 1434062
> Reviewed-on: https://review.gluster.org/16926

Change-Id: I5cd9ae1bcb831555274108b292181ec2a29b6d95
BUG: 1441474
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/17043
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Shyamsundar Ranganathan

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

cluster/ec: Don't trigger data/metadata heal on Lookups

2017-02-27T15:34:08+00:00

Problem-1
If Lookup which doesn't take any locks observes version mismatch it can't be
trusted. If we launch a heal based on this information it will lead to
self-heals which will affect I/O performance in the cases where Lookup is
wrong. Considering self-heal-daemon and operations on the inode from client
which take locks can still trigger heal we can choose to not attempt a heal on
Lookup.

Problem-2:
Fixed spurious failure of
tests/bitrot/bug-1373520.t
For the issues above, what was happening was that ec_heal_inspect()
is preventing 'name' heal to happen

Problem-3:
tests/basic/ec/ec-background-heals.t
To be honest I don't know what the problem was, while fixing
the 2 problems above, I made some changes to ec_heal_inspect() and
ec_need_heal() after which when I tried to recreate the spurious
failure it just didn't happen even after a long time.

 >BUG: 1414287
 >Signed-off-by: Pranith Kumar K 
 >Change-Id: Ife2535e1d0b267712973673f6d474e288f3c6834
 >Reviewed-on: https://review.gluster.org/16468
 >Smoke: Gluster Build System 
 >NetBSD-regression: NetBSD Build System 
 >Reviewed-by: Xavier Hernandez 
 >CentOS-regression: Gluster Build System 
 >Reviewed-by: Ashish Pandey 

BUG: 1419824
Change-Id: I340b48cd416b07890bf3a5427562f5e3f88a481f
Signed-off-by: Pranith Kumar K 
Reviewed-on: https://review.gluster.org/16765
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Xavier Hernandez 
Smoke: Gluster Build System

posix: Fix creation of files with S_ISVTX on FreeBSD

2017-02-20T15:42:51+00:00

On FreeBSD the S_ISVTX flag is completely ignored when creating a
regular file. Since gluster needs to create files with this flag set,
specialy for DHT link files, it's necessary to force the flag.

This fix does this by calling fchmod() after creating a file that
must have this flag set.

> Change-Id: I51eecfe4642974df6106b9084a0b144835a4997a
> BUG: 1411228
> Signed-off-by: Xavier Hernandez 
> Reviewed-on: https://review.gluster.org/16417
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Raghavendra Bhat 
> Reviewed-by: Kaleb KEITHLEY 

Change-Id: I2087516383bd132c59bbab98eda8f2243a2163fe
BUG: 1424973
Signed-off-by: Xavier Hernandez 
Reviewed-on: https://review.gluster.org/16686
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Shyamsundar Ranganathan

libglusterfs: Fix a crash due to race between inode_ctx_set and inode_ref

2017-02-20T12:25:29+00:00

Issue:
Currently inode ref count is guarded by inode_table->lock, and
inode_ctx is guarded by inode->lock. With the new patch [1]
inode_ref was modified to change the inode_ctx to track the ref
count per xlator. Thus inode_ref performed under inode_table->lock
is modifying inode_ctx which has to be modified only under inode->lock

Solution:
When a inode is created, inode_ctx holder is allocated for all the xlators.
Hence in case of inode_ctx_set instead of using the first free index in
inode ctx holder, we can have predecided index for every xlator in the graph.

Credits Pranith K 

[1] http://review.gluster.org/13736

> Reviewed-on: https://review.gluster.org/16622
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Niels de Vos 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Pranith Kumar Karampuri 

Change-Id: I1bfe111c211fcc4fcd761bba01dc87c4c69b5170
BUG: 1423385
Signed-off-by: Poornima G 
Reviewed-on: https://review.gluster.org/16655
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

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

libglusterfs+changetimerecorder: reduce log noise

2017-02-10T19:23:08+00:00

The logging about translator options is so verbose that it
significantly slows down scalability tests - sometimes even to the
point where it induces timing-related failures.  Quiet, please.

Backport of:
> Change-Id: If0766e2a80746bba586e67e6019ff7084d68b425
> Reviewed-on: https://review.gluster.org/16569

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

libglusterfs: fix serious leak of xlator_t structures

2017-02-09T21:01:45+00:00

There's a lot of logic (and some long comments) around how to free
these structures safely, but then we didn't do it.  Now we do.

Backport of:
> Change-Id: I9731ae75c60e99cc43d33d0813a86912db97fd96
> BUG: 1420571
> Reviewed-on: https://review.gluster.org/16570

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

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