glusterfs.git, branch v3.10.0rc0

doc: Updated release notes with details about brick multiplexing

2017-02-03T02:56:26+00:00

Change-Id: Ie1230e262a3cd22feebe79d32d6bcb4f556e0bff
BUG: 1417735
Signed-off-by: Shyam 
Reviewed-on: https://review.gluster.org/16536
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System

doc: Updated release notes

2017-02-03T02:19:26+00:00

Included missing release notes for features that are part of this
release.

Included bugs fixed in this release since release-3.9

Change-Id: I573aade31ffb0809985ecc4e5e224d2439b60856
BUG: 1417735
Signed-off-by: Shyam 
Reviewed-on: https://review.gluster.org/16535
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System

glusterd: double-check whether brick is alive for stats

2017-02-03T00:45:03+00:00

With multiplexing, our tests detach bricks from their host processes
without glusterd being involved.  Thus, when we ask glusterd to fetch
profile info, it will try to fetch from a brick that's actually not
present any more.  While it can handle the process being dead and its
RPC connection being closed, it barfs if it gets a negative response
from a live brick process.  This is not a problem in normal use,
because the brick can't disappear without glusterd seeing it.  The fix
is to double check that the brick is actually running, by looking for
its pidfile which the tests *do* clean up as part of killing a brick.

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

BUG: 1418091
Change-Id: Ia61e273134520c8ccfa3371ee2370cb9a1920877
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16532
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

socket: retry connect immediately if it fails

2017-02-03T00:43:24+00:00

Previously we relied on a complex dance of setting flags, shutting
down the socket, tearing stuff down, getting an event, tearing more
stuff down, and waiting for a higher-level retry.  What we really
need, in the case where we're just trying to connect prematurely e.g.
to a brick that hasn't fully come up yet, is a simple retry of the
connect(2) call.

This was discovered by observing failures in ec-new-entry.t with
multiplexing enabled, but probably fixes other random failures as
well.

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

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

doc: Release notes updated for 'Disabled creation of .trashcan'

2017-02-02T17:59:28+00:00

Change-Id: I97c2559981c3e79d6fabead7dbe0d557ef0793ab
BUG: 1417735
Signed-off-by: Anoop C S 
Reviewed-on: https://review.gluster.org/16524
Smoke: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Shyamsundar Ranganathan 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

tools/glusterfind: delete temporary folder

2017-02-02T17:38:19+00:00

Problem:
Run specific temporary folder created under
/usr/var/lib/misc/glusterfsd/glusterfind///
remains undeleted.

Solution:
Delete the temporary folder from all nodes.

mainline:
> BUG: 1413526
> Reviewed-on: https://review.gluster.org/16416
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Aravinda VK 
(cherry picked from commit 355c1955039a39c820880be72fe77d4e74af0967)

Change-Id: I0edaf868aebb01b15c489434bbb26fe853351384
BUG: 1417527
Signed-off-by: Milind Changire 
Reviewed-on: https://review.gluster.org/16477
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

performance/write-behind: access stub only if available during

2017-02-02T17:36:43+00:00

statedump

>Change-Id: Ia5dd718458a5e32138012f81f014d13fc6b28be2
>BUG: 1415115
>Signed-off-by: Raghavendra G 
>Reviewed-on: https://review.gluster.org/16440
>Reviewed-by: N Balachandran 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Smoke: Gluster Build System 

Change-Id: Ia5dd718458a5e32138012f81f014d13fc6b28be2
BUG: 1418623
Signed-off-by: Raghavendra G 
(cherry picked from commit 85d7f1d1ee24ac400d4aa223478727643532693a)
Reviewed-on: https://review.gluster.org/16519
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

rpc/socket.c : Bonnie++ hangs during rewrites in ganesha + SSL

2017-02-02T17:33:45+00:00

Problem: Bonnie++ rewrite operation hangs in ganesha + SSL environment

Solution: Bonnie++ hangs during execution of rewrite operation in
          ganesha + SSL environment.It was hanged due to blocking on poll
          call in ssl_do because no POLLOUT event was getting on socket.
          Socket is not getting POLLOUT event because all other threads
          are waiting to get lock and lock is not released ssl_do
          because it is not getting any event on poll.To correct it
          update the condition in ssl_do as same in getting error
          SSL_ERROR_WANT_READ.

Test:     To test the patch followed below procedure
          1) Setup 2X2 Ganesha + SSL environment.
          2) Run bonnie from 3 nfs client parallely
          3) After run "Rewwrite operation" by bonnie it is hanged.
          4) After apply the patch it is not hanged.

> BUG: 1418213
> Change-Id: I5985cbbc4cfdac5d287268d791e31c274abc3c8d
> Signed-off-by: Mohit Agrawal 
> Reviewed-on: https://review.gluster.org/16501
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Jeff Darcy 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Vijay Bellur 
> (cherry picked from commit d7077bca4b372a056d23416294e729637e9af94e)

Change-Id: Id029c71382025477bb5ff31f28ec537e4fe58b03
BUG: 1418541
Reviewed-on: https://review.gluster.org/16513
Tested-by: MOHIT AGRAWAL 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

libglusterfs+transport+io-threads: fix 256KB stack abuse

2017-02-02T17:32:49+00:00

Some functions were allocating 64K booleans, which are (crazily)
mapped to 4-byte ints, for a total of 256KB per call.  Changed to use
bitfields instead, so usage is now only 8KB per call.  This was the
impediment to changing the io-threads stack size, so that has been
adjusted too.

Backport of:
> Change-Id: I8781c4f2c8f2b830f4535e366995fac8dd0a8653
> BUG: 1418095
> Reviewed-on: https://review.gluster.org/15745

Change-Id: Ia5dada61703e6bea95f2511da71feb573fc9a429
BUG: 1418536
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16511
Reviewed-by: N Balachandran 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Vijay Bellur 
CentOS-regression: Gluster Build System