glusterfs.git/rpc/xdr, branch bug-deprecated

rdma:rdma fuse mount hangs for tcp,rdma volumes if brick is down.

2014-11-18T07:30:55+00:00

When we try to mount a tcp,rdma volume as rdma
transport using FUSE protocol, then mount will
hang if the brick is down. When we kill a process,
signal will be received in glusterfsd process and
it will call pmap_signout with port listening on tcp only.
In case of the tcp,rdma there will be two ports,
and port which is listening for rdma will not
called for sign out. 
So the mount process will try to connect to a port
which is not open and it will keep trying to connect.
This patch will call pmap_signout for rdma port also,
So when mount tries to get the brick port,it will fail.

Change-Id: I23676f65f96eb90b69b76478f7a21412a6aba70f
BUG: 1143886
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8762
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

Build fix: xdrgen

2014-11-14T06:16:17+00:00

As discovered in https://review.gluster.org/8762, BSD systems fail to
run xdrgen during glusterfs build. This seems to be caused by a
difference between BSD make and GNU make whith implcit targets. The
former seems to use absolute path here, which means we should not
prepend it with the current directory path, otherwise we have the
directory path twice and the files cannot be found my make.

This is a second attempt after I178123bf6f3d9e963ff5b78839d498f530c05a97
which was broken and reverted in I3c8966288f66d0eafa2e94490e3b64a057b4f2c0

BUG: 1157839
Change-Id: I797c536c319a156b71a42c82cbaf80bbf17b7234
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/9046
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Vijay Bellur

Revert "Build fix: xdrgen"

2014-11-04T13:41:32+00:00

This reverts commit 12bc39c144aa41a097435f2aab304ddfbbb9b625

This causes all regression tests to fail. Reverting for now, we can include a
correct fix later.

Change-Id: I3c8966288f66d0eafa2e94490e3b64a057b4f2c0
URL: http://supercolony.gluster.org/pipermail/gluster-devel/2014-November/042759.html
BUG: 1157839
Reported-by: Emmanuel Dreyfus 
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/9040
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

Build fix: xdrgen

2014-11-02T16:41:34+00:00

As discovered in https://review.gluster.org/8762, BSD systems fail to
run xdrgen during glusterfs build. This seems to be caused by a
difference between BSD make and GNU make whith implcit targets. The
former seems to use absolute path here, which means we should not
prepend it with the current directory path, otherwise we have the
directory path twice and the files cannot be found my make.

BUG: 1157839
Change-Id: I178123bf6f3d9e963ff5b78839d498f530c05a97
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/9016
Reviewed-by: Harshavardhana 
Tested-by: Harshavardhana 
Reviewed-by: Humble Devassy Chirammal

porting: OSX/Darwin 10.9 porting issues

2014-08-12T16:02:10+00:00

xdrproc_t() arguments are variadic and non-variadic

On OSX > 10.9
-------------
typedef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);

On OSX < 10.9
------------
typedef bool_t (*xdrproc_t)(XDR *, ...);

FreeBSD all versions
------------
typedef bool_t (*xdrproc_t)(XDR *, ...);

NetBSD 6.1.4
-----------
typedef bool_t (*xdrproc_t)(XDR *, const void *);

Linux all versions
-----------
typedef bool_t (*xdrproc_t)(XDR *, void *,...);

This weird and odd implementations across various platforms
should be handled properly.

Change-Id: Iad8b7da2e5b82526bf3708cff31ab10ce09f59c9
BUG: 1128820
Signed-off-by: Harshavardhana 
Reviewed-on: http://review.gluster.org/8458
Reviewed-by: Emmanuel Dreyfus 
Tested-by: Gluster Build System

build: make GLUSTERD_WORKDIR rely on localstatedir

2014-08-07T08:17:29+00:00

- Break-way from '/var/lib/glusterd' hard-coded previously,
  instead rely on 'configure' value from 'localstatedir'
- Provide 's/lib/db' as default working directory for gluster
  management daemon for BSD and Darwin based installations
- loff_t is really off_t on Darwin
- fix-off the warnings generated by clang on FreeBSD/Darwin
- Now 'tests/*' use GLUSTERD_WORKDIR a common variable for all
  platforms.
- Define proper environment for running tests, define correct PATH
  and LD_LIBRARY_PATH when running tests, so that the desired version
  of glusterfs is used, regardless where it is installed.
  (Thanks to manu@netbsd.org for this additional work)

Change-Id: I2339a0d9275de5939ccad3e52b535598064a35e7
BUG: 1111774
Signed-off-by: Harshavardhana 
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/8246
Tested-by: Gluster Build System

feature/snapshot : Interface to delete all snapshots belonging

2014-07-25T10:23:44+00:00

to a system as-well-as to a particular volume.

Problem :
With the current design we can only delete a single snapshot.
And the deletion of volume which contains snapshot is not allowed.
Because of that user might be forced to delete all the snapshots
manually before he is allowed to delete a volume.

Solution:
Following is the interface with which user can delete
all the snapshots of a system or belonging to a particular volume.

        Syntax : gluster snapshot delete all

        *To delete all the snapshots present in a system

        Syntax : gluster snapshot delete volume 

        *To deletes all the snapshot present in a volume specified.

========================================================================
Sample Output:

Case 1 : Deleting a single snapshot.
[root@snapshot-24 glusterfs]# gluster snapshot delete snap1
Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
snapshot delete: snap1: snap removed successfully

-----------------------------------------------------------------
Case 2 : Deleting all the snapshots in a Volume.
[root@snapshot-24 glusterfs]# gluster snapshot delete volume vol1
Volume (vol1) contains 9 snapshot(s).
Do you still want to continue and delete them?  (y/n) y
snapshot delete: snap2: snap removed successfully
snapshot delete: snap3: snap removed successfully
snapshot delete: snap4: snap removed successfully
snapshot delete: snap5: snap removed successfully
.
.
.

-----------------------------------------------------------------
Case 3 : Deleting all the snapshots in a system.
[root@snapshot-24 glusterfs]# gluster snapshot delete all
System contains 4 snapshot(s).
Do you still want to continue and delete them?  (y/n) y
snapshot delete: snap7: snap removed successfully
snapshot delete: snap8: snap removed successfully
snapshot delete: snap9: snap removed successfully
snapshot delete: snap10: snap removed successfully
========================================================================

Change-Id: Ifec8e128ab2011cbbba208376b9c92cfbe7d8d71
BUG: 1112613
Signed-off-by: Sachin Pandit 
Reviewed-on: http://review.gluster.org/8162
Reviewed-by: Atin Mukherjee 
Tested-by: Gluster Build System 
Reviewed-by: Avra Sengupta 
Reviewed-by: Raghavendra Bhat 
Reviewed-by: Kaushal M

cli/glusterd: Added support for dispersed volumes

2014-07-11T17:34:24+00:00

Two new options have been added to the 'create' command of the cli
interface:

    disperse [] redundancy 

Both are optional. A dispersed volume is created by specifying, at
least, one of them. If 'disperse' is missing or it's present but
'' does not, the number of bricks enumerated in the command
line is taken as the disperse count.

If 'redundancy' is missing, the lowest optimal value is assumed. A
configuration is considered optimal (for most workloads) when the
disperse count - redundancy count is a power of 2. If the resulting
redundancy is 1, the volume is created normally, but if it's greater
than 1, a warning is shown to the user and he/she must answer yes/no
to continue volume creation. If there isn't any optimal value for
the given number of bricks, a warning is also shown and, if the user
accepts, a redundancy of 1 is used.

If 'redundancy' is specified and the resulting volume is not optimal,
another warning is shown to the user.

A distributed-disperse volume can be created using a number of bricks
multiple of the disperse count.

Change-Id: Iab93efbe78e905cdb91f54f3741599f7ea6645e4
BUG: 1118629
Signed-off-by: Xavier Hernandez 
Reviewed-on: http://review.gluster.org/7782
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Vijay Bellur

mgmt/glusterd: display snapd status as part of volume status

2014-07-01T05:30:58+00:00

* Made changes to save the port used by snapd in the info file for the volume
  i.e. /vols//info

This is how the gluster volume status of a volume would look like for which the
uss feature is enabled.

[root@tatooine ~]# gluster volume status vol
Status of volume: vol
Gluster process                                         Port    Online  Pid
------------------------------------------------------------------------------
Brick tatooine:/export1/vol                             49155   Y       5041
Snapshot Daemon on localhost                            49156   Y       5080
NFS Server on localhost                                 2049    Y       5087

Task Status of Volume vol
------------------------------------------------------------------------------
There are no active volume tasks

Change-Id: I8f3e5d7d764a728497c2a5279a07486317bd7c6d
BUG: 1111041
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/8114
Tested-by: Gluster Build System 
Reviewed-by: Kaushal M

Get snapshot info dynamically via new rpc and infra for snapview-server to refresh snaplist

2014-06-15T17:33:23+00:00

BUG: 1105439
Change-Id: I4bb312a53d88f6f4955e69a3ef2b4955ec17f26d
Signed-off-by: Anand Subramanian 
Reviewed-on: http://review.gluster.org/8001
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur