glusterfs.git/xlators/features/snapview-server/src/snapview-server.h, branch v5.11

Land clang-format changes

2018-09-12T11:52:48+00:00

Change-Id: I6f5d8140a06f3c1b2d196849299f8d483028d33b

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

features/snapview-server: properly go through the list of snapshots

2018-06-14T15:49:02+00:00

The comparison code to check whether a glfs instance is valid
(i.e. whether it corresponds to one in the list of current snapshots)
was not correct and was not comparing all the snapshots

Change-Id: I87c58edb47bd9ebbb91d805e45df2c4baf2c8118
fixes: bz#1589842
Signed-off-by: Raghavendra Bhat

Coverity Issue: PW.INCLUDE_RECURSION in several files

2017-11-09T13:21:11+00:00

Coverity ID: 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417,
418, 419, 423, 424, 425, 426, 427, 428, 429, 436, 437, 438, 439,
440, 441, 442, 443

Issue: Event include_recursion

Removed redundant, recursive includes from the files.

Change-Id: I920776b1fa089a2d4917ca722d0075a9239911a7
BUG: 789278
Signed-off-by: Girjesh Rajoria

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: do not #include "config.h" in each file

2015-05-29T12:43:17+00:00

Instead of including config.h in each file, and have the additional
config.h included from the compiler commandline (-include option).

When a .c file tests for a certain #define, and config.h was not
included, incorrect assumtions were made. With this change, it can not
happen again.

BUG: 1222319
Change-Id: I4f9097b8740b81ecfe8b218d52ca50361f74cb64
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/10808
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Pranith Kumar Karampuri

uss: CIFS gives error while accessing .snaps directory

2014-12-03T14:47:24+00:00

CIFS sends getxattr call while accessing .snaps directory.
snapview server should return ENODATA if getxattr is called
on .snaps folder. Also flush on .snaps folder should be handled.

Windows client sends and getxattr call on the parent folder
of .snaps with a special key to get the real filename of a file.
This is used by samba to do case insensitive check of files.

Fixed few FreeBSD compilation error.

bug: 1168875

Change-Id: I74d5cb4419568c8ed8709ba6d1ddff0e41392204
Signed-off-by: Rajesh Joseph 
Reviewed-on: http://review.gluster.org/9211
Reviewed-by: Raghavendra Bhat 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

uss/gluster: creating file/directories inside .snaps should fail with

2014-11-13T14:55:11+00:00

EROFS

When an attempt is made to create file/directories inside .snaps, it
fails with wrong error message as "Stale file handle". It should fail
with "Read-only file system"

Change-Id: I3a812a0afc4762cbb71ab180b9394c866e576a66
BUG: 1159840
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/9039
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

USS : Display only the activated snapshots

2014-11-12T11:20:10+00:00

Instead of displaying all the snapshots in the uss world,
it is better if we display only the activated snapshots.

Change-Id: I70d3ec212b62ec15956ae3e826bc4201d8dedd17
BUG: 1155042
Signed-off-by: Sachin Pandit 
Reviewed-on: http://review.gluster.org/8958
Tested-by: Gluster Build System 
Reviewed-by: Avra Sengupta 
Reviewed-by: Rajesh Joseph 
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Krishnan Parthasarathi