glusterfs.git/xlators/features/snapview-server, branch v3.10.8

build: out-of-tree builds generates files in the wrong directory

2016-09-18T16:34:37+00:00

And minor cleanup of a few of the Makefile.am files while we're
at it.

Rewrite the make rules to do what xdrgen does. Now we can get rid
of xdrgen.

Note 1. netbsd6's sed doesn't do -i. Why are we still running
smoke tests on netbsd6 and not netbsd7? We barely support netbsd7
as it is.

Note 2. Why is/was libgfxdr.so (.../rpc/xdr/src/...) linked with
libglusterfs? A cut-and-paste mistake? It has no references to
symbols in libglusterfs.

Note3. "/#ifndef\|#define\|#endif/" (note the '\'s) is a _basic_
regex that matches the same lines as the _extended_ regex
"/#(ifndef|define|endif)/". To match the extended regex sed needs to
be run with -r on Linux; with -E on *BSD. However NetBSD's and
FreeBSD's sed helpfully also provide -r for compatibility. Using a
basic regex avoids having to use a kludge in order to run sed with
the correct option on OS X.

Note 4. Not copying the bit of xdrgen that inserts copyright/license
boilerplate. AFAIK it's silly to pretend that machine generated
files like these can be copyrighted or need license boilerplate.
The XDR source files have their own copyright and license; and
their copyrights are bound to be more up to date than old
boilerplate inserted by a script. From what I've seen of other
Open Source projects -- e.g. gcc and its C parser files generated
by yacc and lex -- IIRC they don't bother to add copyright/license
boilerplate to their generated files.

It appears that it's a long-standing feature of make (SysV, BSD,
gnu) for out-of-tree builds to helpfully pretend that the source
files it can find in the VPATH "exist" as if they are in the $cwd.
rpcgen doesn't work well in this situation and generates files
with "bad" #include directives.

E.g. if you `rpcgen ../../../../$srcdir/rpc/xdr/src/glusterfs3-xdr.x`,
you get an #include directive in the generated .c file like this:

  ...
  #include "../../../../$srcdir/rpc/xdr/src/glusterfs3-xdr.h"
  ...

which (obviously) results in compile errors on out-of-tree build
because the (generated) header file doesn't exist at that location.
Compared to `rpcgen ./glusterfs3-xdr.x` where you get:

  ...
  #include "glusterfs3-xdr.h"
  ...

Which is what we need. We have to resort to some Stupid Make Tricks
like the addition of various .PHONY targets to work around the VPATH
"help".

Warning: When doing an in-tree build, -I$(top_builddir)/rpc/xdr/...
looks exactly like -I$(top_srcdir)/rpc/xdr/...  Don't be fooled though.
And don't delete the -I$(top_builddir)/rpc/xdr/... bits

Change-Id: Iba6ab96b2d0a17c5a7e9f92233993b318858b62e
BUG: 1330604
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/14085
Tested-by: Niels de Vos 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Niels de Vos

snapview-server: fix unused variable warnings/errors

2016-09-12T16:19:46+00:00

http://review.gluster.org/14085 fixes a/the "leak" - via the
generated rpc/xdr headers - of pragmas that mask these warnings.

However 14085 won't pass the smoke test until all the warnings are
fixed.

Change-Id: I74cf7adf943f71e0de8d8f487db3cd2394ce16e8
BUG: 1369124
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15251
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Krutika Dhananjay 
Reviewed-by: Rajesh Joseph

core: add a basis function to reduce verbose code

2016-07-18T11:59:05+00:00

Change-Id: Icebe1b865edb317685e93f3ef11d98fd9b2c2e9a
BUG: 1357226
Signed-off-by: Zhou Zhengping 
Reviewed-on: http://review.gluster.org/14936
Reviewed-by: Niels de Vos 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

snapshot/uss: log is filled with gfid is NULL error

2016-05-25T14:22:55+00:00

In snapview-server if the lookup came on missing entry
then it does not have proper context to see if it is the
case of "Stale file handle" or ENOENT. We should not log
this error in GF_LOG_ERROR level, instead this should be
a debug log.

Change-Id: I8f7cc0e117e9a6dd9482da2e94a56f2ed731a442
BUG: 1339149
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/14514
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

uss/gluster: generate gfid for snapshot files from snapname and gfid

2016-03-10T10:43:24+00:00

If 'a' and 'b' are hardlinks, we need to generate a virtual
gfid for these files so that the inode number for 'a' and 'b'
are same.

Generate gfid as below:
gfid_of_a = MD5(snapname + back_end_gfid(a))
if '/dir1/a' and '/dir2/b' are hardlinks, then inode number should be
same for
all below files:
/mnt/.snaps/snap1/dir1/a
/mnt/.snaps/snap1/dir2/b
/mnt/dir1/.snaps/snap1/a
/mnt/dir2/.snaps/snap1/b

Change-Id: Ifda793455610e554f3f1e4cbb90d44c02cda4b0f
BUG: 1171703
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/9255
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Rajesh Joseph

build: export minimum symbols from xlators for correct resolution

2015-12-22T17:15:01+00:00

Revisiting http://review.gluster.org/#/c/11814/, which unintentionally
introduced warnings from libtool about the xlator .so names.

According to [1], the -module option must appear in the Makefile.am
file(s); if -module is defined in a macro, e.g. in configure(.ac),
then libtool will not recognize that this is a module and will emit a
warning.

[1]
http://www.gnu.org/software/automake/manual/automake.html#Libtool-Modules

Change-Id: Ifa5f9327d18d139597791c305aa10cc4410fb078
BUG: 1248669
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/13003
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: soumya k 
Reviewed-by: Niels de Vos

build: export minimum symbols from xlators for correct resolution

2015-09-24T14:37:42+00:00

We've been lucky that we haven't had any symbol collisions until now.
Now we have a collision between the snapview-client's svc_lookup() and
libntirpc's svc_lookup() with nfs-ganesha's FSAL_GLUSTER and libgfapi.

As a short term solution all the snapview-client's FOP methods were
changed to static scope. See http://review.gluster.org/11805. This
works in snapview-client because all the FOP methods are defined in
a single source file. This solution doesn't work for other xlators
with FOP methods defined in multiple source files.

To address this we link with libtool's '-export-symbols $symbol-file'
(a wrapper around `ld --version-script ...` --- on linux anyway) and
only export the minimum required symbols from the xlator sharedlib.

N.B. the libtool man page says that the symbol file should be named
foo.sym, thus the rename of *.exports to *.sym. While foo.exports
worked, we will follow the documentation.

Signed-off-by: Kaleb S. KEITHLEY 
BUG: 1248669
Change-Id: I1de68b3e3be58ae690d8bfb2168bfc019983627c
Reviewed-on: http://review.gluster.org/11814
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: soumya k 
Reviewed-by: Niels de Vos

uss : handle `buf` variable properly in svs_glfs_readdir()

2015-09-07T18:20:25+00:00

The svs_glfs_readdir() is a generic function which is called from
svs_readdir() and svs_readdirp(). But in svs_readdir 'buf' variable
is passed as NULL, then glfs_read_readdir() will fail. This patch
will fix the same.

Change-Id: Id02e4e17e30c85de117db5ddd9f97b578622dff9
BUG: 1260611
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/12117
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

libgfapi: adding 'follow' flag to glfs_h_lookupat()

2015-08-24T16:21:51+00:00

Previously glfs_h_lookupat won't follow the symlink, this patch
introduces new flag `follow` which will resolve the same. Applications
linking against the new library will need to use the new glfs_h_lookupat
API call.

In order to stay compatible with existing binaries that use the previous
glfs_h_lookupat() function, the old symbol needs to stay available.

Verification that there are two versions of glfs_h_lookupat:

  $ objdump -T /usr/lib64/libgfapi.so.0 | grep -w glfs_h_lookupat
  0000000000015070 g    DF .text  000000000000021e  GFAPI_3.7.4 glfs_h_lookupat
  0000000000015290 g    DF .text  0000000000000008 (GFAPI_3.4.2) glfs_h_lookupat

Testing with a binary (based on anonymous_fd_read_write.c from ./tests/)
that was linked against the old library:

  $ objdump -T ./lookupat | grep -w glfs_h_lookupat
  0000000000000000      DF *UND*  0000000000000000  GFAPI_3.4.2 glfs_h_lookupat

Enable debugging for 'ld.so' so that we can check that the GFAPI_3.4.2
version of the symbol gets loaded:

  $ export LD_DEBUG_OUTPUT=lookupat.ld.log LD_DEBUG=all
  $ ./lookupat
  $ grep -w glfs_h_lookupat lookupat.ld.log.2543
  2543:     symbol=glfs_h_lookupat;  lookup in file=./lookupat [0]
  2543:     symbol=glfs_h_lookupat;  lookup in file=/lib64/libgfapi.so.0 [0]
  2543:     binding file ./lookupat [0] to /lib64/libgfapi.so.0 [0]: normal symbol `glfs_h_lookupat' [GFAPI_3.4.2]

Change-Id: I8bf9b1c19a0585f681bc1a7f84aad1ccd0f75f6a
BUG: 1252410
Signed-off-by: Jiffin Tony Thottan 
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/11883
Reviewed-by: soumya k 
Reviewed-by: Kaleb KEITHLEY 
Tested-by: NetBSD Build System

rpc: add owner xlator argument to rpc_clnt_new

2015-08-13T06:12:50+00:00

The @owner argument tells RPC layer the xlator that owns
the connection and to which xlator THIS needs be set during
network notifications like CONNECT and DISCONNECT.

Code paths that originate from the head of a (volume) graph and use
STACK_WIND ensure that the RPC local endpoint has the right xlator saved
in the frame of the call (callback pair). This guarantees that the
callback is executed in the right xlator context.

The client handshake process which includes fetching of brick ports from
glusterd, setting lk-version on the brick for the session, don't have
the correct xlator set in their frames. The problem lies with RPC
notifications. It doesn't have the provision to set THIS with the xlator
that is registered with the corresponding RPC programs. e.g,
RPC_CLNT_CONNECT event received by protocol/client doesn't have THIS set
to its xlator. This implies, call(-callbacks) originating from this
thread don't have the right xlator set too.

The fix would be to save the xlator registered with the RPC connection
during rpc_clnt_new. e.g, protocol/client's xlator would be saved with
the RPC connection that it 'owns'. RPC notifications such as CONNECT,
DISCONNECT, etc inherit THIS from the RPC connection's xlator.

Change-Id: I9dea2c35378c511d800ef58f7fa2ea5552f2c409
BUG: 1235582
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/11436
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G