Spurious failures fix for bug-948729.t and bug-948729-mode-script.t

Change I816b36e1d3e6933f92acf19d9be8eeaaa333356e causes sprurious
failures in bug-948729.t and bug-948729-mode-script.t
This seems to be caused by leftover information in /d/backends/
probably in a dot-prefixed directory.

Attempt to fix this by removing /d/backends and other work directories
on cleanup. While there we test and report failure to remove anything.

BUG: 1129939
Change-Id: I0373c7f3c507db8ab509e8fd3aca2a386bea807e
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/9081
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Tested-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
glusterd/snapshot: mount snapshot volume with read-only option

Snapshot volumes are readonly. If you mount the volume to the client it
doesn't allow writes, but its attributes are rw which contradicts the
functionality.

mount script should set read-only attributes for snapshot volumes.

Change-Id: I056253abd8dfe7b2b43a064fbdbd9c16b8eca679
BUG: 1132946
Signed-off-by: vmallika <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/8518
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Avra Sengupta <asengupt@redhat.com>
Reviewed-by: Rajesh Joseph <rjoseph@redhat.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
cli: for rpc timeout throw a time out message

Change-Id: I9660df1c3b2707583bd95806011b650cd1a2df1b
BUG: 1161037
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-on: http://review.gluster.org/9017
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaushal M <kaushal@redhat.com>
store: fix compile warning in gf_store_unlock()

The following warning is logged when building on Fedora 20:

  store.c:712:15: warning: ignoring return value of 'lockf', declared
  with attribute warn_unused_result [-Wunused-result]

It does not really matter if unlocking fails, close() will release the
lock in any case. But, log the error in case close() can not finish and
hangs indefinitely (is that possible?).

Change-Id: If6c832f9aec10da6c1adb761b13b58e22d38a065
BUG: 1009076
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/9078
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>