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

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

2016-03-23T11:03:52+00:00

This is a backport of http://review.gluster.org/#/c/9255/

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 

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

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

2015-09-09T12:16:39+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.

It is backport of http://review.gluster.org/12117

Upstream Reference:
> Change-Id: Id02e4e17e30c85de117db5ddd9f97b578622dff9
> BUG: 1260611
> Signed-off-by: Jiffin Tony Thottan 
> cherry-picked as 7b6183c36ebfe020b724c95b018a8cd535e1ecdd

Change-Id: Iee08d5c29cad0376ca9d378c8f17b0820eebc88a
BUG: 1260859
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/12122
Tested-by: NetBSD Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System

libgfapi: adding 'follow' flag to glfs_h_lookupat()

2015-08-25T12:31:35+00:00

This patch is backport of http://review.gluster.org/#/c/11883/

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]

This change has been successfully cherry-picked as 1ead86a8bcbfe4045729466e4b98f765f3c13c8d
in master

Upstream reference
>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 
Signed-off-by: Jiffin Tony Thottan 

Change-Id: Idbbf0cd6802f86c53b16377d90d08ff6d99e7b08
BUG: 1256616
Reviewed-on: http://review.gluster.org/12009
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY

rpc: add owner xlator argument to rpc_clnt_new

2015-08-14T10:10:47+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: 1253212
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 
(cherry picked from commit f7668938cd7745d024f3d2884e04cd744d0a69ab)
Reviewed-on: http://review.gluster.org/11908
Reviewed-by: Pranith Kumar Karampuri

uss : implement statfs fop for snapd

2015-05-10T15:51:54+00:00

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

snapview-client and snapview-server doesnot have statfs
fop implemented

Change-Id: I2cdd4c5784414b0549a01af9a28dbc723b7cdc67
BUG: 1218741
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/10740
Tested-by: NetBSD Build System
Reviewed-by: Niels de Vos 
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System

snapshot: correct error message in snapshot helper

2015-04-08T18:01:33+00:00

Change-Id: Ic01a5d4115383f1245bae3fba2bf92e23c8213ff
BUG: 1194640
Signed-off-by: Humble Devassy Chirammal 
Reviewed-on: http://review.gluster.org/9747
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Niels de Vos

snapview: Fixing the coverity issues

2015-04-04T18:00:47+00:00

Coverity CIDs:
1228601
1220056
1238185
1257624

Change-Id: Idb4cc3b44bc3ccb8b497ce355e1e3bacfb176db9
BUG: 789278
Signed-off-by: Nandaja Varma 
Reviewed-on: http://review.gluster.org/9615
Tested-by: Gluster Build System 
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

features/snapview-server: Fixing explicit null dereferencing.

2015-03-31T08:19:53+00:00

CID: 1238184
The pointer was not checked for null before
dereferencing in the 'out' label, which is
resolved now.

Change-Id: I8aa7520102b84f63727754b8ac9c1f87ef8a6671
BUG: 789278
Signed-off-by: arao 
Reviewed-on: http://review.gluster.org/9662
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

avoid memory leaks in snapview-server

2015-01-08T10:05:14+00:00

* snapview-server in readdirp, creates the inode for entries with names "." and
  ".." for each readdirp operation without creating dentries leading to memleak.
  It should have avoided creation of inodes for those entries

Change-Id: I3b2025fd10872fcc3303d0becec764ffd4e37601
BUG: 1179663
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/9404
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur