glusterfs.git/libglusterfs, branch v3.4.0beta2

nfs: change default nfs port to 2049

2013-05-23T19:13:53+00:00

This change makes it possible to mount glusterfs volumes
without specifying vers=3 option.

Change-Id: If5a974e2bdfd2adbeac3d82af774310cdf30f988
BUG: 832939
Signed-off-by: Rajesh Amaravathi 
Reviewed-on: http://review.gluster.org/4840
Reviewed-by: Niels de Vos 
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/5078
Reviewed-by: Anand Avati

syncop: synctask shouldn't yawn, it could miss a 'wake'

2013-05-23T14:24:42+00:00

        Backport of http://review.gluster.org/5058

Change-Id: I7731fd33ca0c925cc52f8d105275b44fc625a1e2
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5071
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

syncop: Remove task from syncbarrier's waitq before 'wake'

2013-05-21T13:03:40+00:00

        Backport of http://review.gluster.org/5047

Removing task from syncbarrier's waitq after wake could result in a
subsequent syncbarrier_wake, wake'ing up the already running task.  This
fix makes the removal from waitq and wake 'atomic'

The root cause and the fix are similar in spirit to what was observed
in synclock's waitq implementation.

Change-Id: I7dd9e6ad5945742bcda20eb5a06a9376bb18528e
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5054
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

syncop: Update synctask state appropriately

2013-05-21T13:03:14+00:00

        Backport of http://review.gluster.org/4985

* Earlier, SYNCOP macro, the only consumer of synctask_yield, would set
the task->state to SYNCTASK_SUSPEND. Today, we have glusterd having its
own wrapper macros which don't set task's state. There is also the
syncbarrier and synclock framework, which also participate in a
synctask's scheduling (and need to keep a task's state up to date). It
only makes more sense to leave a synctask's state to the synctask
library, since its an internal affair.

* Need to 'yawn' before 'yield' to avoid re-running tasks to set
  task->woken appropriately.

Change-Id: Ic7a59e6ebcc46f03e53223ca237668d45a3cba40
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/5053
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Refresh glusterd-syncop fixes from master

2013-05-17T03:44:44+00:00

Following commits were cherry-picked from master,
044f8ce syncop: Remove task from synclock's waitq before 'wake'
cb6aeed glusterd: Give up big lock before performing any RPC
46572fe Revert "glusterd: Fix spurious wakeups in glusterd syncops"
5021e04 synctask: implement barriers around yield, not the other way
4843937 glusterd: Syncop callbks should take big lock too

Change-Id: I5ae71ab98f9a336dc9bbf0e7b2ec50a6ed42b0f5
BUG: 948686
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/4938
Reviewed-by: Amar Tumballi 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati 
Reviewed-on: http://review.gluster.org/5021
Reviewed-by: Vijay Bellur

libglusterfs: avoid the logging which says the port is invalid

2013-05-09T03:10:18+00:00

If the reserved ports file in proc contains just a newline, then
do not proceed with ports checking and reserving.

Change-Id: I776d0be1c3824dcd982f0685b171f2172b4e11e6
BUG: 762989
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4821
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Fix uninitialized mutex usage in synctask_destroy

2013-05-04T07:32:22+00:00

synctask_new() initialize task->mutex is task->synccbk is NULL.
synctask_done() calls synctask_destroy() if task->synccbk is not NULL.
synctask_destroy() always destroys the mutex.

Fix that by checking for task->synccbk in synctask_destroy()

This is a backport of I50bb53bc6e2738dc0aa830adc4c1ea37b24ee2a0

BUG: 764655
Change-Id: I3d6292f05a986ae3ceee35161791348ce3771c12
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/4920
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

syncenv: be robust against spurious wake()s

2013-04-17T12:46:09+00:00

In the current implementation, when the callers of synctasks perform
a spurious wake() of a sleeping synctask (i.e, an extra wake() soon
after a wake() which already woke up a yielded synctask), there is
now a possibility of two sync threacs picking up the same synctask.
This can result in a crash. The fix is to change ->slept = 0|1 and
membership of synctask in runqueue atomically.

Today we dequeue a task from the runqueue in syncenv_task(), but
reset ->slept = 0 much later in synctask_switchto() in an unlocked
manner -- which is safe, when there are no spurious wake()s.

However, this opens a race window where, if a second wake() happens
after the dequeue, but before setting ->slept = 0, it results in
queueing the same synctask in the runqueue once again, and get
picked up by a different synctask.

This is has been diagnosed to be the crashes in the regression tests
of http://review.gluster.org/4784. However that patch still has a
spurious wake() [the trigger for this bug] which is yet to be fixed.

BUG: 948686
Change-Id: I51858e887cad2680e46fb973629f8465f4429363
Original-author: Anand Avati 
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/4833
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System

synctask: introduce synclocks for co-operative locking

2013-04-17T08:53:20+00:00

This patch introduces a synclocks - co-operative locks for synctasks.
Synctasks yield themselves when a lock cannot be acquired at the time
of the lock call, and the unlocker will wake the yielded locker at
the time of unlock.

The implementation is safe in a multi-threaded syncenv framework.

It is also safe for sharing the lock between non-synctasks. i.e, the
same lock can be used for synchronization between a synctask and
a regular thread. In such a situation, waiting synctasks will yield
themselves while non-synctasks will sleep on a cond variable. The
unlocker (which could be either a synctask or a regular thread) will
wake up any type of lock waiter (synctask or regular).

Usage:

    Declaration and Initialization
    ------------------------------

    synclock_t lock;

    ret = synclock_init (&lock);
    if (ret) {
        /* lock could not be allocated */
    }

   Locking and non-blocking lock attempt
   -------------------------------------

   ret = synclock_trylock (&lock);
   if (ret && (errno == EBUSY)) {
      /* lock is held by someone else */
      return;
   }

   synclock_lock (&lock);
   {
      /* critical section */
   }
   synclock_unlock (&lock);

BUG: 763820
Change-Id: I23066f7b66b41d3d9fb2311fdaca333e98dd7442
Signed-off-by: Krishnan Parthasarathi 
Original-author: Anand Avati 
Reviewed-on: http://review.gluster.org/4830
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

rpc: before freeing the volume options object, delete it from the list

2013-04-12T17:07:23+00:00

* Suppose there is an xlator option which is considered by the xlator
  only if the source was built with debug mode enabled (the only example
  in the current code base is run-with-valgrind option for glusterd), then
  giving that option would make the process crash if the source was not
  built with debug mode enabled.

  Reason:
  In rpc, after getting the options symbol dynamically, it was stored in the
  newly allocated volume options structure and the structure's list head was
  added to the xlator's volume_options list. But while freeing the structure
  the list was not deleted. Thus when the list was traversed, already freed
  structure was accessed leading to segfault.

Change-Id: I3e9e51dd2099e34b206199eae7ba44d9d88a86ad
BUG: 922877
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/4687
Reviewed-by: Amar Tumballi 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/4818
Reviewed-by: Jeff Darcy