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

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 <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4774
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
nfs3-server: call truncate fop only if necessary

* nfs3svc_setattr_cbk: only truncate if requested size != current size
Expand gluster's NFS FD header to 4 bytes

* https://bugzilla.redhat.com/show_bug.cgi?id=950121
* Oracle's DNFS does not properly XDR encoding on NFS FDs that
  are not congruent to 0mod4 bytes long
* This patch is a workaround to support Oracle's buggy code
performance/io-cache: check the inode context to be NULL before accessing

Change-Id: I475af7f8ffd5e5d8adbd2a74af20e56ad7751f69
BUG: 958108
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-on: http://review.gluster.org/4916
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
nfs/mount3: fix crash in subdir resolution

* __mnt3_resolve_export_subdir_comp: if nfs_entry_loc_fill fails,
  mres->resolveloc does not contain valid data
* gf_log should use 'gfid' instead of mres->resolveloc.inode->gfid
* fixes a crash if program flow gets to this line

Change-Id: Idb0d6f97ea73eaf9056d28267ad7a42aa8cf6579
nfs: handle stable write with @flags rather than fsync()

stable writes can be "made stable" by simply setting O_SYNC (or
O_DSYNC, accordingly) in the write flags or fd->flags. Performing
fsync() at the end of the write is extremely inefficient and completely
messes up eager-locking logic in AFR.

Change-Id: I4d954c133641e246b2ab4df874bad0282667561f
BUG: 916372
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4591
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
storage/posix: honor O_SYNC and O_DSYNC sent in @flags of writev()

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 <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4738
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Fix spurious brick disconnects

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 <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/4908
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-by: Anand Avati <avati@redhat.com>