glusterfs.git/xlators/features/snapview-server/src/snapview-server-helpers.c, branch v7.0rc0

features/snapview-server: use the same volfile server for gfapi options

2019-07-18T13:11:04+00:00

snapview server xlator makes use of "localhost" as the volfile server while
initing the new glfs instance to talk to a snapshot. While localhost is fine,
better use the same volfile server that was used to start the snapshot
daemon containing the snapview-server xlator.

Change-Id: I4485d39b0e3d066f481adc6958ace53ea33237f7
fixes: bz#1728391
Signed-off-by: Raghavendra Bhat 
(cherry picked from commit 36f6e6df0ff15d0464b869803710adca2b65e8ba)

libglusterfs: Move devel headers under glusterfs directory

2018-12-05T21:47:04+00:00

libglusterfs devel package headers are referenced in code using
include semantics for a program, this while it works can be better
especially when dealing with out of tree xlator builds or in
general out of tree devel package usage.

Towards this, the following changes are done,
- moved all devel headers under a glusterfs directory
- Included these headers using system header notation <> in all
code outside of libglusterfs
- Included these headers using own program notation "" within
libglusterfs

This change although big, is just moving around the headers and
making it correct when including these headers from other sources.

This helps us correctly include libglusterfs includes without
namespace conflicts.

Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b
Updates: bz#1193929
Signed-off-by: ShyamsundarR

features/snapview-server: change gf_log instances to gf_msg

2018-11-05T07:05:23+00:00

Change-Id: Ib8bdf210a896423abcd7413dd4896d424ac0f561
fixes: bz#1626610
Signed-off-by: Raghavendra Bhat

mgmt/glusterd: use proper path to the volfile

2018-10-04T05:02:35+00:00

Till now, glusterd was generating the volfile path for the snapshot
volume's bricks like this.

/snaps//

But in reality, the path to the brick volfile for a snapshot volume is

/snaps///

The above workaround was used to distinguish between a mount command used
to mount the snapshot volume, and a brick of the snapshot volume, so that
based on what is actually happening, glusterd can return the proper volfile
(client volfile for the former and the brick volfile for the latter). But,
this was causing problems for snapshot restore when brick multiplexing is
enabled. Because, with brick multiplexing, it tries to find the volfile
and sends GETSPEC rpc call to glusterd using the 2nd style of path i.e.

/snaps///

So, when the snapshot brick (which is multiplexed) sends a GETSPEC rpc
request to glusterd for obtaining the brick volume file, glusterd was
returning the client volume file of the snapshot volume instead of the
brick volume file.

Change-Id: I28b2dfa5d9b379fe943db92c2fdfea879a6a594e
fixes: bz#1635050
Signed-off-by: Raghavendra Bhat

Land part 2 of clang-format changes

2018-09-12T12:22:45+00:00

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu

features/uss: Use xxh64 to generate gfid instead of md5sum

2018-09-05T13:13:21+00:00

* This is to ensure FIPS support
* Also changed the signature of svs_uuid_generate to
  get xlator argument
* Added xxh64 wrapper functions in common-utils to
  generate gfid using xxh64
  - Those wrapper functions can be used by other xlators
    as well to generate gfids using xxh64. But as of now
    snapview-server is going to be the only consumer.

Change-Id: Ide66573125dd74122430cccc4c4dc2a376d642a2
Updates: #230
Signed-off-by: Raghavendra Manjunath 
Signed-off-by: Raghavendra Bhat

features/snapview-server: validate the fs instance before doing fop there

2018-08-24T04:18:55+00:00

    PROBLEM:
    ========

    USS design depends on snapview-server translator communicating with each
    individual snapshot via gfapi. So, the snapview-server xlator maintains
    the glfs instance (thus the snapshot) to which a inode belongs to by
    storing it inside the inode context.

    Suppose, a file from a snapshot is opened by a application, and the fd
    is still valid from application's point of view (i.e. application has
    not yet closed fd). Now, if the snapshot to which the opened file
    belongs to is deleted, then the glfs_t instance corresponding to the
    snapshot is destroyed by snapview-server as part of snap deletion.
    But now, if the application does IO on the fd it has kept open, then
    snapview server tries to send that request to the corresponding snap
    via glfs instance for that snapshot stored in the inode context for
    the file on which the application is sending the fop. And this results
    in freed up glfs_t pointer being accessed and causes a segfault.

    FIX:
    ===

    For fd based operations, check whether the glfs instance that the inode
    contains in its context, is still valid or not.

    For non fd based operations, usually lookup should guarantee that. But
    if the file was already looked up, and the client accessing the snap data
    (either NFS, or native glusterfs fuse) does not bother to send a lookup
    and directly sends a path based fop, then that path based fop should
    ensure that the fs instance is valid.

Change-Id: I881be15ec46ecb51aa844d7fd41d5630f0d644fb
updates: bz#1602070
Signed-off-by: Raghavendra Bhat

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

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