porting: use __builtin_ffsll() instead of ffsll()

- NetBSD/Darwin doesn't implement ffsll()
- use Compiler builtin

Change-Id: Iee78b4b81747b0bd3877fd2fcb98746f642ce080
BUG: 764655
Signed-off-by: Harshavardhana <harsha@harshavardhana.net>
Reviewed-on: http://review.gluster.org/8308
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-by: Justin Clift <justin@gluster.org>
glusterd: Correctly reset volinfo->caps during volume create

Change-Id: I012899be08a06d39ea5c9fb98a66acf833d7213f
BUG: 1120589
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/8323
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: Krishnan Parthasarathi <kparthas@redhat.com>
dht: fix rename race

If two clients try to rename the same file at the same time, we
sometimes end up with *no file at all* in either the old or new
location.  That's kind of bad.  The culprit seems to be some overly
aggressive cleanup code.  AFAICT, based on today's study of the code,
the intent of the changed section is to remove any linkfile we might
have created before the actual rename.  However, what we're removing
might not be our extra link.  If we're racing with another client that's
also doing a rename, it might be the only remaining link to the user's
data.  The solution, which is good enough to pass this test but almost
certainly still not complete, is to be more selective about when we do
this unlink.  Now, we only do it if we know that, at some point, we did
in fact create the link without error (notably ENOENT on the source or
EEXIST on the destination) ourselves.

Change-Id: I8d8cce150b6f8b372c9fb813c90be58d69f8eb7b
BUG: 1117851
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/8269
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
DHT/Create : Failing to identify a linkto file in lookup_everywhere_cbk path

In case a file is not found in its cached subvol we proceed with
dht_lookup_everywhere. But as we dont add the linkto xattr to the
dictionary, we fail to identify any linkto file encountered.The
implication being we end up thinking the linkto file as a regular file
and proceed with the fop.

Change-Id: Iab02dc60e84bb1aeab49182f680c0631c33947e2
BUG: 1117923
Signed-off-by: Susant Palai <spalai@redhat.com>
Reviewed-on: http://review.gluster.org/8277
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>