glusterfs.git, branch v3.4.0beta1

posix: fix dangerous "sharing" of fd in readdir between two requests

2013-05-07T18:54:33+00:00

posix_fill_readdir() is a multi-step function which performs many
readdir() calls, and expects the directory cursor to have not
"seeked away" elsewhere between two successive iterations. Usually
this is not a problem as each opendir() from an application has its
own backend fd, and there is nobody else to "seek away" the directory
cursor. However in case of NFS's use of anonymous fd, the same fd_t
is shared between all NFS readdir requests, and two readdir loops can
be executing in parallel on the same dir dragging away the cursor in
a chaotic manner.

The fix in this patch is to lock on the fd around the loop. Another
approach could be to reimplement posix_fill_readdir() with a single
getdents() call, but that's for another day.

Change-Id: Ia42e9c7fbcde43af4c0d08c20cc0f7419b98bd3f
BUG: 948086
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/4774
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/4963

extras: /etc/init.d/glusterd should create a lockfile under /var/lock/sybsys

2013-05-07T18:48:25+00:00

Without a lockfile under /var/lock/subsys, the glusterd service is not
stopped on shutdown or reboot.

Change-Id: Ib2c28821061ed0fd374731681a81f3fd8e989193
BUG: 960476
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/4961
Reviewed-by: Kaleb KEITHLEY 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

storage/posix: honor O_SYNC and O_DSYNC sent in @flags of writev()

2013-05-07T18:02:10+00:00

Historic bug - posix_writev() has been inspecting pfd->flushwrites for
performing fsync() after write, instead of @flags for O_SYNC|O_DSYNC.

pfd->flushwrites was never set anywhere and is unused completely. This
is behavior from the time before anonymous FD where open() had @wbflags
param. This is a leftover from that cleanup.

Change-Id: Id9bfe562a60db4eb3bd0a7705bdba91f2df2f3ec
BUG: 916372
Signed-off-by: Anand Avati 
Reviewed-on: http://review.gluster.org/4738
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-on: http://review.gluster.org/4962

cluster/afr: Turn on eager-lock for fd DATA transactions

2013-05-07T12:00:05+00:00

Problem:
With the present implementation, eager-lock is issued for
any fd fop. eager-lock is being transferred to metadata
transactions. But the lk-owner is set to local->fd address
only for DATA transactions, but for METADATA transactions
it is frame->root. Because of this unlock on the eager-lock fails
and rebalance hangs.

Fix:
Enable eager-lock for fd DATA transactions

This is a backport of change If30df7486a0b2f5e4150d3259d1261f81473ce8a
http://review.gluster.org/#/c/4588/

BUG: 916226
Change-Id: Id41ac17f467c37e7fd8863e0c19932d7b16344f8
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/4899
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

performance/io-cache: Avoid double mem_put in ioc_readv

2013-05-07T11:39:44+00:00

On readv error io-cache frame->local is not set to NULL
so the local is mem_put in STACK_DESTROY as well. This
patch sets frame->local to NULL in all cases.

BUG: 955751
Change-Id: I4a7340189efe02473452986b5870b02fcfa9038e
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4886
Reviewed-by: Raghavendra G 
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

Fix spurious brick disconnects

2013-05-01T03:12:52+00:00

Spurious disconnect were caused by a race condition inside
rpc_transport_ref()/rpc_transport_unref() that allowed the refcount
to drop to zero while the transport was still in use. The race
condition is made possible because of an uninitiaized mutex
produced when socket_server_event_handler() copies the transport

This is a backport of I34fe097a0ac21b0dbf58f5eed84880e3fd9814f2

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

extras: include Fedora changes in init.d/glusterd

2013-04-30T00:07:46+00:00

The changes in the .spec file from Fedora have largely been merged into
the glusterfs.spec.in. It seems that some dependencies have been missed,
most importantly some additions to the init-script that are called while
(un)installing or updating RPMs.

These changes come from the downstream Fedora package that carries its
own glusterd.init script. In future, Fedora/EPEL should be able to drop
that file and use the Gluster project version.

BUG: 954149
Change-Id: I7d25622ffa52228451e742b539f1f092eac57b6b
URL: http://lists.nongnu.org/archive/html/gluster-devel/2013-04/msg00077.html
CC: Fedora GlusterFS Packagers 
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/4865
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Anand Avati

build: sync glusterfs.spec.in with Fedora glusterfs.spec

2013-04-26T15:17:02+00:00

BUG: 819130
Change-Id: I96aeb8fbe8b79bbc058ff9a45167d822abb576ed
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/4877
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

glusterd: big lock - a coarse-grained locking to prevent races

2013-04-17T12:48:50+00:00

There are primarily three lists that are part of glusterd process,
that are concurrently accessed. Namely, priv->volumes, priv->peers
and volinfo->bricks_list.

Big-lock approach
-----------------
WHAT IS IT?
Big lock is a coarse-grained lock which protects all three
lists, mentioned above, from racy access.

HOW DOES IT WORK?
At any given point in time, glusterd's thread(s) are in execution
_iff_ there is a preceding, inbound network event. Of course, the
sigwaiter thread and timer thread are exceptions.
A network event is an external trigger to glusterd, via the epoll
thread, in the form of POLLIN and POLLERR.
As long as we take the big-lock at all such entry points and yield
it when we are done, we are guaranteed that all the network events,
accessing the global lists, are serialised.

This amounts to holding the big lock at
- all the handlers of all the actors in glusterd. (POLLIN)
- all the cbks in glusterd. (POLLIN)
- rpc_notify (DISCONNECT event), if we access/modify
  one of the three lists. (POLLERR)

In the case of synctask'ized volume operations, we must remember that,
if we held the big lock for the entire duration of the handler,
we may block other non-synctask rpc actors from executing.
For eg, volume-start would block in PMAP SIGNIN, if done incorrectly.
To prevent this, we need to yield the big lock, when we yield the
synctask, and reacquire on waking up of the synctask.

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