glusterfs.git/xlators/protocol/server/src, branch v3.7.2

protocol/server : port log messages to a new framework

2015-06-15T05:25:00+00:00

        Backport of http://review.gluster.org/#/c/9874/

Cherry picked from dc089a1a51988c2b407040e1684d7b0adbd79556
> Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/9874
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
BUG: 1217722
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/10552
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

Changing log level from Warning to Debug

2015-06-08T13:21:30+00:00

Change-Id: Ie9bf338802e3f1c59c92d2749a1f8bc745dc5455
BUG: 1228100
Signed-off-by: Ashish Pandey 
Reviewed-on: http://review.gluster.org/10998
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

protocol/client,server: Move EEXIST logs in mkdir and mknod to DEBUG level

2015-05-29T02:24:41+00:00

        Backport of: http://review.gluster.org/10791

Change-Id: I096296f0b97f62f49577ca698ae34e28cce4a4b4
BUG: 1225919
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/10973
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System

Upcall: Replaced opaque gfid with string in rpc cbk args

2015-05-07T11:19:41+00:00

For GF_CBK_CACHE_INVALIDATION, have changed the type of gfid
to be string (cannonical form) instead of opaque byte format
to ensure correctness across platforms supporting different
endianness.

BUG: 1217711
Change-Id: Iac4372714f4b4ebcd9c4393aaf46ceba3f37f587
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/10224
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/10563
Tested-by: NetBSD Build System
Tested-by: Gluster Build System

Upcall: Process each of the upcall events separately

2015-05-07T11:19:16+00:00

As suggested during the code-review of Bug1200262, have modified
GF_CBK_UPCALL to be exlusively GF_CBK_CACHE_INVALIDATION.
Thus, for any new upcall event, a new CBK procedure will be added.

Also made changes to store upcall data separately based on the
upcall event type received.

BUG: 1217711
Change-Id: I0f5e53d6f5ece16aecb514a0a426dca40fa1c755
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/10049
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/10562
Tested-by: NetBSD Build System
Tested-by: Gluster Build System

protocol: increase default group-cache-timeout to 300 seconds

2015-05-06T17:34:22+00:00

sssd uses 300 seconds by default too. There is no need to overload sssd
with requests that it would have cached.

Cherry picked from commit 34833364e9839f0036bccd58ec0a8a963e69263e:
> BUG: 1215187
> Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
> Signed-off-by: Niels de Vos 
> Reviewed-on: http://review.gluster.org/10371
> Tested-by: Gluster Build System 
> Reviewed-by: Kaleb KEITHLEY 
> Reviewed-by: Vijay Bellur 

Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
BUG: 1215189
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10523
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Vijay Bellur

rpc: Maintain separate xlator pointer in 'rpcsvc_state'

2015-05-05T13:29:20+00:00

The structure 'rpcsvc_state', which maintains rpc server
state had no separate pointer to track the translator.
It was using the mydata pointer itself. So callers were
forced to send xlator pointer as mydata which is opaque
(void pointer) by function prototype.

'rpcsvc_register_init' is setting svc->mydata with xlator
pointer. 'rpcsvc_register_notify' is overwriting svc->mydata
with mydata pointer. And rpc interprets svc->mydata as
xlator pointer internally. If someone passes non xlator
structure pointer to rpcsvc_register_notify as libgfchangelog
currently does, it might corrupt mydata. So interpreting opaque
mydata as xlator pointer is incorrect as it is caller's choice
to send mydata as any type of data to 'rpcsvc_register_notify'.

Maintaining two different pointers in 'rpcsvc_state' for xlator
and mydata solves the issue.

BUG: 1218381
Change-Id: I4c28937a30845e3f41b6fc7a09036149c816659b
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/10366
Reviewed-on: http://review.gluster.org/10534
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Aravinda VK 
Reviewed-by: Vijay Bellur

Avoid conflict between contrib/uuid and system uuid

2015-04-04T17:48:35+00:00

glusterfs relies on Linux uuid implementation, which
API is incompatible with most other systems's uuid. As
a result, libglusterfs has to embed contrib/uuid,
which is the Linux implementation, on non Linux systems.
This implementation is incompatible with systtem's
built in, but the symbols have the same names.

Usually this is not a problem because when we link
with -lglusterfs, libc's symbols are trumped. However
there is a problem when a program not linked with
-lglusterfs will dlopen() glusterfs component. In
such a case, libc's uuid implementation is already
loaded in the calling program, and it will be used
instead of libglusterfs's implementation, causing
crashes.

A possible workaround is to use pre-load libglusterfs
in the calling program (using LD_PRELOAD on NetBSD for
instance), but such a mechanism is not portable, nor
is it flexible. A much better approach is to rename
libglusterfs's uuid_* functions to gf_uuid_* to avoid
any possible conflict. This is what this change attempts.

BUG: 1206587
Change-Id: I9ccd3e13afed1c7fc18508e92c7beb0f5d49f31a
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/10017
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos

core: Add inode context merge callback

2015-03-24T13:34:33+00:00

Certain translators may require to update the inode context
of an already linked inode before unwinding the call to the
client. Normally, such a case in encountered during parallel
operations when a fresh inode is chosen at call (wind) time.
In the callback path, one of inodes is successfully linked
in the inode table, thereby the other inodes being thrown
away (and the inode pointers for these calls being pointed
to the linked inode).

Translators which may have strict dependency on the correct
value in the inode context would get stale values in inode
context. This patch introduces a new callback which provides
gives translators an opportunity to "patch" their respective
inode contexts. Note that, as of now, this callback is only
invoked during create()s unwind path. Although this might
needed to be done for all dentry fops and lookup, but let
that be done as an when required (bitrot stub requires
this *only* for create()).

Change-Id: I6cd91c2af473c44d1511208060d3978e580c67a6
BUG: 1170075
Original-Author: Raghavendra Bhat 
Original-Author: Venky Shankar 
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/9913
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

every/where: add GF_FOP_IPC for inter-translator communication

2015-03-17T14:02:15+00:00

Several features - e.g. encryption, erasure codes, or NSR - involve
multiple cooperating translators which sometimes need a "private" means
of communication amongst themselves.  Historically we've used virtual or
synthetic xattrs, but that's not very elegant and clutters up the
getxattr/setxattr path which must also handle real xattr requests.  This
new fop should address that.

The only argument is an int32_t "op" which should be recognized by the
target translator.  It is recommended that translators using these
feature follow some convention regarding the ops that they define, to
avoid conflicts.  Using a hash of the target translator's type string as
a base for a series of ops would probably be a good start.  Any other
information can be passed in both directions using xdata.

The default behavior for this fop, as with any other, is to pass through
to FIRST_CHILD.  That makes use of this fop "transparent" to other
translators that were written before it existed, but it also means that
it only really works with pass-through translators.  If a routing
translator (such as DHT) or a fan-out translator (such as AFR) is
involved, the IPC might not reach its intended destination unless those
translators are modified to forward IPC fops along all paths.

If an IPC gets all the way to storage/posix it is considered an error,
much like an uncaught exception.  We don't actually *do* anything in
that case, but we do log it send back an EOPNOTSUPP error.  This makes
the "unrecognized opcode" condition distinguishable from the "no IPC
support" condition (which would yield an RPC error instead) so clients
can probe for the presence of a handler for their own favorite opcode
and either use that or use old-school xattrs depending on the result.

BUG: 1158628
Signed-off-by: Venky Shankar 
Signed-off-by: Jeff Darcy 
Change-Id: I84af1b17babe5b30ec03ecf027ae37d09b873968
Reviewed-on: http://review.gluster.org/8812
Reviewed-by: Vijay Bellur