dht: do not remove linkfile if file exist in cached sub volume

Currently with rmdir, if a directory contains only the linkfiles
we remove all the linkfiles and this is causing the problem when the cached
sub volume is down and end-up with duplicate files showing on the mount point.

Solution: Before removing a linkfile check if the
files exists in cached subvolume.

Change-Id: Iedffd0d9298ec8bb95d5ce27c341c9ade81f0d3c
BUG: 1042725
Signed-off-by: Vijaykumar M <vmallika@redhat.com>
Reviewed-on: http://review.gluster.org/6500
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>
geo-rep: Fixing a memory leak issue reported by Coverity

Issue: "errmsg" is allocated memory through  GF_CALLOC in function "gf_strdup"

Fix: using GF_FREE to free the memory

Change-Id: Iee8f8d806ea995591feee8e4ed0a0798ad07a8c4
BUG: 789278
Signed-off-by: Lalatendu Mohanty <lmohanty@redhat.com>
Reviewed-on: http://review.gluster.org/6740
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
build: GFAPI_VERSION should be 6.0.0 not 0.0.6

------------------------------------->
"In essence, every time you make a change to the library and
release it, the C:R:A should change. A new library should
start with 0:0:0. Each time you change the public interface
(i.e., your installed header files), you should increment the
CURRENT number."

So the version which was 3 became 5 when discard API was added
and became 6 when zerofill was added. As per the above description,
API addition will result in a change to the installed header (glfs.h)
and hence warrants a change in CURRENT number ? Should you have
changed the version to 6.0.0 instead of 0.0.6 ?
<------------------------------------

Thanks Bharata B Rao <bharata.rao@gmail.com> for pointing this out

Change-Id: I0aa980a6713fbd28922a94c5debb170a89aa3512
BUG: 862082
Signed-off-by: Harshavardhana <harsha@harshavardhana.net>
Reviewed-on: http://review.gluster.org/6790
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Bharata B Rao <bharata.rao@gmail.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
tests: Fix regression failures

Change-Id: I83dc651a5ce87adf51d1f539400cd91c801fc460
BUG: 1045309
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
Reviewed-on: http://review.gluster.org/6874
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaushal M <kaushal@redhat.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
glusterd: Fix race in pid file update

This patch only removes lines of code. For personal gratification, giving a
detailed explanation of what the problem was.

When glusterd spawns the local brick process, say when a reboot of the node
occurs,the glusterd_brick_start() and subsequently the
glusterd_volume_start_glusterfs() function gets called twice; from
glusterd_spawn_daemons() and glusterd_do_volume_quorum_action() respectively.
This causes a race, best described by a pseudo-code of current behaviour.

glusterd_volume_start_glusterfs()
{
       if(!brick process running) {

         step-a) reap pid file( i.e. unlink it)
         step-b) fork a brick process which creates and locks pid file and
                 binds the process to a socket.

        }

}

Time            Event
----            -----
T1              Call-1 arrives, completes step-a, starts step-b
T2              Call-2 arrives, enters step-a as Call-1's forked child is not
                yet running.
T3              Call-1's forked child is alive, creates pidfile and locks it,binds
                its address to a socket.
T4              Call-2 performs step-a; i.e.unlinks the pid file created by Call-1 !!
                (files can still be stil be unlinked despite a lockf on it)
T5              Call-2 does step-b, and the forked child process creates a *new* pid file
                with it's pid and locks this file.
T6              But Call-2's brick process is not able to bind to socket as it
                is already in use (courtesy T3) and hence exits (so no locks anymore on the pidfile).

Result:
-  Pid file now contains PID of an extinct brick process.
- `gluster volume status` shows this PID value. It also notices that there is no
lock held on pid file by the currently running brick process (created by Call-1)
and hence shows N/A for the online status.

Also, as a result of events at T4, "ls  -l /proc/<brick process PID>/fd/pidfile"
shows up as deleted.

Fix:
1.Do not unlink pid file. i.e. avoid step-a. Now at T5,Call-2's brick process
cannot obtain lock on pid file (Call-1's process still holds it) and exits.

2. Unrelated, but remove lock-unlock sequence in glusterfs_pidfile_setup()
which does not seem to be doing anything useful.

Change-Id: I18d3e577bb56f68d85d3e0d0bfd268e50ed4f038
BUG: 1035586
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
Reviewed-on: http://review.gluster.org/6786
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
mount.glusterfs/glusterfsd: Add dummy deprecated *fetch-attempts options

volfile-max-fetch-attempts and fetch-attempts were not deprecated
properly at 'b610f1be7cd71b8f3e51c224c8b6fe0e7366c8cf'.

Provide a way for backward compatibility for broken third party apps.

Change-Id: I597b50df08823e74691c5a20a4da4d13aab4b7ff
BUG: 1045309
Signed-off-by: Harshavardhana <harsha@harshavardhana.net>
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Reviewed-on: http://review.gluster.org/6544
Reviewed-by: Humble Devassy Chirammal <humble.devassy@gmail.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
cluster/dht: Abandoned memory if a call fails

If the call to dict_set_dynstr() fails, the memory indicated by
xattr_buf will not have been stored in the dictionary, so it must be
freed.

Patch set 2: Added a missed call to GF_FREE().  Fixed a formatting
             consistency issue.

Patch set 3: Cleaned a minor style nit.

BUG: 789278
CID: 1124786

Change-Id: Id1f85bd2cbfac0b8727a3f6901f0a50ba921817d
Signed-off-by: Christopher R. Hertel <crh@redhat.com>
Reviewed-on: http://review.gluster.org/6826
Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>
cluster/dht: Fix layout sorting

The layout was not being sorted in the ascending order leading
to the wrong detection of holes/overlaps.

From looking at the previous git commits it appears that the initial version itself had the err comparison code.
Deductions from the current dht_layout_sort():
1. The zero'ed out layouts should be in the from of list, if needed
2. The layout should be sorted in the ascending order of layout error value.
3. The layout should be sorted in the ascending order of the layout 'start'.
But In some cases, with the err comparison code its not sorted in the ascending order. Example: If the input is as below for dht_layout_sort(), the sorting doesn't happen in ascending order.
Input:
0-1 err:0    2-3 err:0   6-7 err:0    0-0 err:20   4-5 err:0
          
With the current sort, Output:
4-5 err:0    0-0 err:0    0-1 err:0    2-3 err:0    6-7 err:0
Expected: 0-0 err:20 0-1 err:0 2-3 err:0 4-5 err:0 6-7 err:0
Looking at dht_layout_anomalies() it appears that, it doesn't require the layout to be sorted based on error value.
The other solution was to replace line 468 with:
 if ((layout->list[i].err || layout->list[j].err) && (layout->list[i].start > layout->list[j].start))
Since dht_layout_anomalies() didn't expect the layout to be sorted based on the error, removed the err comparison.

Change-Id: I1215f6cd53efc7dba01c0958ba6cc7609dab6ff5
BUG: 1056406
Signed-off-by: Poornima G <pgurusid@redhat.com>
Reviewed-on: http://review.gluster.org/6757
Reviewed-by: Anand Avati <avati@redhat.com>
Tested-by: Anand Avati <avati@redhat.com>
quota: Fixing a possibility of GF_FREE on an array pointer

Issue: when the charecter pointer is not heap allocated by the program
we should not do GF_FREE on it.

Change-Id: Ibccc25491a9ab924fd5b82c14566f551a061ec2e
BUG: 789278
Signed-off-by: Lalatendu Mohanty <lmohanty@redhat.com>
Reviewed-on: http://review.gluster.org/6741
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
glusterd: Bump MAX_OP_VERSION to 4

Change-Id: Ib017a7d8ad8017bdcf15035018f4d04ecb5560e9
BUG: 1059206
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/6853
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>