glusterfs.git/xlators/features/snapview-server, branch v6.8 performance/md-cache: Do not skip caching of null character xattr values 2019-08-28T08:29:47+00:00 Anoop C S anoopcs@redhat.com 2019-08-10T05:00:26+00:00 6e7597e10c23aa0dea13fc4c390cb201cd22f1f7 Null character string is a valid xattr value in file system. But for those xattrs processed by md-cache, it does not update its entries if value is null('\0'). This results in ENODATA when those xattrs are queried afterwards via getxattr() causing failures in basic operations like create, copy etc in a specially configured Samba setup for Mac OS clients. On the other side snapview-server is internally setting empty string("") as value for xattrs received as part of listxattr() and are not intended to be cached. Therefore we try to maintain that behaviour using an additional dictionary key to prevent updation of entries in getxattr() and fgetxattr() callbacks in md-cache. Credits: Poornima G <pgurusid@redhat.com> Change-Id: I7859cbad0a06ca6d788420c2a495e658699c6ff7 Fixes: bz#1743782 Signed-off-by: Anoop C S <anoopcs@redhat.com> (cherry picked from commit b4b683736367d93daad08a5ee6ca95778c07c5a4) 
Null character string is a valid xattr value in file system. But for
those xattrs processed by md-cache, it does not update its entries if
value is null('\0'). This results in ENODATA when those xattrs are
queried afterwards via getxattr() causing failures in basic operations
like create, copy etc in a specially configured Samba setup for Mac OS
clients.

On the other side snapview-server is internally setting empty string("")
as value for xattrs received as part of listxattr() and are not intended
to be cached. Therefore we try to maintain that behaviour using an
additional dictionary key to prevent updation of entries in getxattr()
and fgetxattr() callbacks in md-cache.

Credits: Poornima G <pgurusid@redhat.com>

Change-Id: I7859cbad0a06ca6d788420c2a495e658699c6ff7
Fixes: bz#1743782
Signed-off-by: Anoop C S <anoopcs@redhat.com>
(cherry picked from commit b4b683736367d93daad08a5ee6ca95778c07c5a4)
features/snapview-server: obtain the list of snapshots inside the lock 2019-08-01T10:45:16+00:00 Raghavendra Bhat raghavendra@redhat.com 2019-07-02T20:50:23+00:00 f51491e684f79c87ee1f7b406f8c748d7e2bf8d7 The current list of snapshots from priv->dirents is obtained outside the lock. Change-Id: I8876ec0a38308da5db058397382fbc82cc7ac177 Fixes: bz#1731509 (cherry picked from commit 8e795617fd6f5193d0d52a336059ce1a28108c0e) 
The current list of snapshots from priv->dirents is obtained outside
the lock.

Change-Id: I8876ec0a38308da5db058397382fbc82cc7ac177
Fixes: bz#1731509
(cherry picked from commit 8e795617fd6f5193d0d52a336059ce1a28108c0e)
features/snapview-server: use the same volfile server for gfapi options 2019-07-16T05:00:24+00:00 Raghavendra Bhat raghavendra@redhat.com 2019-06-25T14:51:33+00:00 99977a7b694f6ee137e7b749f04e0cc744dd17e3 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#1727984 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> (cherry picked from commit 36f6e6df0ff15d0464b869803710adca2b65e8ba) 
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#1727984
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
(cherry picked from commit 36f6e6df0ff15d0464b869803710adca2b65e8ba)
rpc: use address-family option from vol file 2019-01-22T13:47:19+00:00 Milind Changire mchangir@redhat.com 2019-01-22T06:40:59+00:00 b6c417785e54620331ae35d6971fe8bef98b4619 This patch helps enable IPv6 connections in the cluster. The default address-family is IPv4 without using this option explicitly. When address-family is set to "inet6" in the /etc/glusterfs/glusterd.vol file, the mount command-line also needs to have -o xlator-option="transport.address-family=inet6" added to it. This option also gets added to the brick command-line. Snapshot and gfapi use-cases should also use this option to pass in the inet6 address-family. Change-Id: I97db91021af27bacb6d7578e33ea4817f66d7270 fixes: bz#1635863 Signed-off-by: Milind Changire <mchangir@redhat.com> 
This patch helps enable IPv6 connections in the cluster.
The default address-family is IPv4 without using this option explicitly.

When address-family is set to "inet6" in the /etc/glusterfs/glusterd.vol
file, the mount command-line also needs to have
-o xlator-option="transport.address-family=inet6" added to it.

This option also gets added to the brick command-line.
Snapshot and gfapi use-cases should also use this option to pass in the
inet6 address-family.

Change-Id: I97db91021af27bacb6d7578e33ea4817f66d7270
fixes: bz#1635863
Signed-off-by: Milind Changire <mchangir@redhat.com>
gfapi: update returned/callback pre/post attributes to glfs_stat 2019-01-07T14:43:27+00:00 ShyamsundarR srangana@redhat.com 2018-12-20T20:28:37+00:00 1a3c2a48e7cd44f2cc8b7b5384321d289aedab8e Change-Id: Ie0fe971e694101aa011d66aa496d0644669c2c5a Updates: #389 Signed-off-by: Kinglong Mee <mijinlong@open-fs.com> Signed-off-by: ShyamsundarR <srangana@redhat.com> 
Change-Id: Ie0fe971e694101aa011d66aa496d0644669c2c5a
Updates: #389
Signed-off-by: Kinglong Mee <mijinlong@open-fs.com>
Signed-off-by: ShyamsundarR <srangana@redhat.com>
xlator: make 'xlator_api' mandatory 2018-12-13T09:11:50+00:00 Amar Tumballi amarts@redhat.com 2018-12-06T10:54:52+00:00 af7e957b4954bd84b8f7df6bfbd59c939092ead2 * Remove the options to load old symbol. * keep only 'xlator_api' symbol from being exported using xlator.sym * add xlator_api to all the xlators where its missing NOTE: This covers all the xlators which has at least a test case to validate its loading. If there is a translator, which doesn't have any test, then we should probably remove that from codebase. fixes: #164 Change-Id: Ibcdc8c9844cda6b4463d907a15813745d14c1ebb Signed-off-by: Amar Tumballi <amarts@redhat.com> 
* Remove the options to load old symbol.
* keep only 'xlator_api' symbol from being exported using xlator.sym
* add xlator_api to all the xlators where its missing

NOTE: This covers all the xlators which has at least a test case
to validate its loading. If there is a translator, which doesn't
have any test, then we should probably remove that from codebase.

fixes: #164
Change-Id: Ibcdc8c9844cda6b4463d907a15813745d14c1ebb
Signed-off-by: Amar Tumballi <amarts@redhat.com>
libglusterfs: Move devel headers under glusterfs directory 2018-12-05T21:47:04+00:00 ShyamsundarR srangana@redhat.com 2018-11-29T19:08:06+00:00 20ef211cfa5b5fcc437484a879fdc5d4c66bbaf5 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 <srangana@redhat.com> 
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 <srangana@redhat.com>
clang: Fix clang warnings in snapview-server.c 2018-11-29T20:41:07+00:00 ShyamsundarR srangana@redhat.com 2018-11-29T20:37:23+00:00 e74d997f0d7eeb91fe6b5f0f0c3969bf4ac53f9f The warning by clang is due to the fact that we check for frame->root to be NULL, but in stack unwind, we ignore the same. If frame is non-NULL then frame->root is non-NULL as frame creation ensures this. Further, across the code we do not check both frame and frame->root for validity. Hence to fix these clang issues, removing the check for frame->root in the various functions. NOTE: Initially clang reported 14 issues in the file, but post commit 6eabefe6 the number reduced to 4, unsure why as that commit does not address this issue. Change-Id: I04b63f2d006a1f95773aae9f904b4bd3d5118e62 Updates: bz#1622665 Signed-off-by: ShyamsundarR <srangana@redhat.com> 
The warning by clang is due to the fact that we check for
frame->root to be NULL, but in stack unwind, we ignore the
same.

If frame is non-NULL then frame->root is non-NULL as frame
creation ensures this. Further, across the code we do not
check both frame and frame->root for validity.

Hence to fix these clang issues, removing the check for
frame->root in the various functions.

NOTE: Initially clang reported 14 issues in the file, but
post commit 6eabefe6 the number reduced to 4, unsure why as
that commit does not address this issue.

Change-Id: I04b63f2d006a1f95773aae9f904b4bd3d5118e62
Updates: bz#1622665
Signed-off-by: ShyamsundarR <srangana@redhat.com>
snapview-server: close the gfapi handle present in a forgotten inode 2018-11-20T11:21:36+00:00 Raghavendra Bhat raghavendra@redhat.com 2018-10-31T20:31:35+00:00 650b5c5271abeb0eef59ac1ebb0ea3c8c37023ab Currently, the snapdaemon can reach the lru limit of the inode table and start sending forgets on the inodes that are least recently used. snapview-server maintains the mapping between the domain of the snapdaemon and the gfapi instance which it uses to access the snapshots via a handle that is stored in the inode context of snapdaemon's inode. The handle is glfs_h_object structure which itself points to the actual inode present in the gfapi world. But, when snapview-server receives forget on a inode, it deleted the inode context without actually closing the handle it had obtained to map the inode from snapdaemon to the inode in gfapi world. So, this change makes sure that, the handle is closed as part of the inode forget. And this closure of the handle will result in gfapi world receiving forget and unref on its corresponding inode. But care must be taken to ensure before the closure to ensure that the gfapi instance from which the handle came from, is still valid and not destroyed. Otherwise, sending a forget downward to the gfapi world might result in the access of freed pointers. Hence, the snapview-server xlator first checks whether that gfapi instance is still there or not and then proceeds with closure of the handle. Change-Id: Ia7bb45112d0c651cc95f2e54d33d925dbd6955b0 fixes: bz#1646728 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> 
Currently, the snapdaemon can reach the lru limit of the inode table
and start sending forgets on the inodes that are least recently used.
snapview-server maintains the mapping between the domain of the
snapdaemon and the gfapi instance which it uses to access the snapshots
via a handle that is stored in the inode context of snapdaemon's inode.
The handle is glfs_h_object structure which itself points to the actual
inode present in the gfapi world.

But, when snapview-server receives forget on a inode, it deleted the
inode context without actually closing the handle it had obtained to
map the inode from snapdaemon to the inode in gfapi world.

So, this change makes sure that, the handle is closed as part of the
inode forget. And this closure of the handle will result in gfapi
world receiving forget and unref on its corresponding inode. But
care must be taken to ensure before the closure to ensure that
the gfapi instance from which the handle came from, is still valid
and not destroyed. Otherwise, sending a forget downward to the gfapi
world might result in the access of freed pointers. Hence, the
snapview-server xlator first checks whether that gfapi instance is
still there or not and then proceeds with closure of the handle.

Change-Id: Ia7bb45112d0c651cc95f2e54d33d925dbd6955b0
fixes: bz#1646728
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
features/snapview-server: change gf_log instances to gf_msg 2018-11-05T07:05:23+00:00 Raghavendra Bhat raghavendra@redhat.com 2018-10-16T19:34:20+00:00 643c9d049de970d27b2bfa806c4d47ea6eabefe6 Change-Id: Ib8bdf210a896423abcd7413dd4896d424ac0f561 fixes: bz#1626610 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> 
Change-Id: Ib8bdf210a896423abcd7413dd4896d424ac0f561
fixes: bz#1626610
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>