summaryrefslogtreecommitdiffstats
path: root/xlators/features
Commit message (Collapse)AuthorAgeFilesLines
* core: make gf_thread_create() easier to useXavi Hernandez2019-02-012-11/+3
| | | | | | | | | | | | | | This patch creates a specific function to set the thread name using a string format and a variable argument list, like printf(). This function is used to set the thread name from gf_thread_create(), which now accepts a variable argument list to create the full name. It's not necessary anymore to use a local array to build the name of the thread. This is done automatically. Change-Id: Idd8d01fd462c227359b96e98699f8c6d962dc17c Updates: bz#1193929 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* feature/bitrot: Avoid thread creation if xlator is not enabledMohit Agrawal2019-01-311-8/+64
| | | | | | | | | | | | | Problem: Avoid thread creation for bitrot-stub for a volume if feature is not enabled Solution: Before thread creation check the flag if feature is enabled Updates: #475 Change-Id: I2c6cc35bba142d4b418cc986ada588e558512c8e Signed-off-by: Mohit Agrawal <moagrawal@redhat.com> Signed-off-by: Kotresh HR <khiremat@redhat.com>
* features/sdfs: disable by defaultAmar Tumballi2019-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the feature enabled, some of the performance testing results, specially those which create millions of small files, got approximately 4x regression compared to version before enabling this. On master without this patch: 765 creates/sec On master with this patch : 3380 creates/sec Also there seems to be regression caused by this in 'ls -l' workload. On master without this patch: 3030 files/sec On master with this patch : 16610 files/sec This is a feature added to handle multiple clients parallely operating (specially those which race for file creates with same name) on a single namespace/directory. Considering that is < 3% of Gluster's usecase right now, it makes sense to disable the feature by default, so we don't penalize the default users who doesn't bother about this usecase. Also note that the client side translators, specially, distribute, replicate and disperse already handle the issue upto 99.5% of the cases without SDFS, so it makes sense to keep the feature disabled by default. Credits: Shyamsunder <srangana@redhat.com> for running the tests and getting the numbers. Change-Id: Iec49ce1d82e621e9db25eb633fcb1d932e74f4fc Updates: bz#1670031 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* Multiple files: reduce work while under lock.Yaniv Kaul2019-01-294-18/+22
| | | | | | | | | | | | | | | | | Mostly, unlock before logging. In some cases, moved different code that was not needed to be under lock (for example, taking time, or malloc'ing) to be executed before taking the lock. Note: logging might be slightly less accurate in order, since it may not be done now under the lock, so order of logs is racy. I think it's a reasonable compromise. Compile-tested only! updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I2438710016afc9f4f62a176ef1a0d3ed793b4f89
* features/shard: Ref shard inode while adding to fsync listKrutika Dhananjay2019-01-241-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PROBLEM: Lot of the earlier changes in the management of shards in lru, fsync lists assumed that if a given shard exists in fsync list, it must be part of lru list as well. This was found to be not true. Consider this - a file is FALLOCATE'd to a size which would make the number of participant shards to be greater than the lru list size. In this case, some of the resolved shards that are to participate in this fop will be evicted from lru list to give way to the rest of the shards. And once FALLOCATE completes, these shards are added to fsync list but without a ref. After the fop completes, these shard inodes are unref'd and destroyed while their inode ctxs are still part of fsync list. Now when an FSYNC is called on the base file and the fsync-list traversed, the client crashes due to illegal memory access. FIX: Hold a ref on the shard inode when adding to fsync list as well. And unref under following conditions: 1. when the shard is evicted from lru list 2. when the base file is fsync'd 3. when the shards are deleted. Change-Id: Iab460667d091b8388322f59b6cb27ce69299b1b2 fixes: bz#1669077 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* afr/self-heal:Fix wrong type checkingRavishankar N2019-01-241-4/+8
| | | | | | | | | | gf_dirent struct has d_type variable which should check with DT_DIR istead of IA_IFDIR or IA_IFDIR has to compare with entry->d_stat.ia_type Change-Id: Idf1059ce2a590734bc5b6adaad73604d9a708804 updates: bz#1653359 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* rpc: use address-family option from vol fileMilind Changire2019-01-221-1/+4
| | | | | | | | | | | | | | | | | 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>
* locks/fencing: Add a security knob for fencingSusant Palai2019-01-222-9/+31
| | | | | | | | | | | | | There is a low level security issue with fencing since one client can preempt another client's lock. This patch does not completely eliminate the issue of a client misbehaving, but certainly it adds a security layer for default use cases that does not need fencing. Change-Id: I55cd15f2ed1ae0f2556e3d27a2ef4bc10fdada1c updates: #466 Signed-off-by: Susant Palai <spalai@redhat.com>
* quotad: fix wrong memory freeKinglong Mee2019-01-213-19/+7
| | | | | | | | | | | | | | | | 1. cli_req.dict.dict_val, It must be freed no metter operation error or success. Fix it as lookup "alloca" memory before decode. 2. args.xdata.xdata_val, It is allocated by "alloca", free is unneeded. 3. qd_nameless_lookup, It olny needs gfid, a gfs3_lookup_req argument is unneeded. Change-Id: I746dddf7f3d1465b1885af2644afe0bcf0a5665b fixes: bz#1656682 Signed-off-by: Kinglong Mee <mijinlong@open-fs.com>
* core: Feature added to accept CidrIp in auth.allowRinku Kothiya2019-01-181-1/+1
| | | | | | | | | | | | | | | Added functionality to gluster volume set auth.allow command to accept CIDR IP addresses. Modified few functions to isolate cidr feature so that it prevents other gluster commands such as peer probe to use cidr format ip. The functions are modified in such a way that they have an option to enable accepting of cidr format for other gluster commands if required in furture. updates: bz#1138841 Change-Id: Ie6734002a7078f1820e5df42d404411cce945e8b Credits: Mohit Agrawal Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* lock: Add fencing supportSusant Palai2019-01-176-122/+708
| | | | | | | | | | | | | | | | | design reference: https://review.gluster.org/#/c/glusterfs-specs/+/21925/ This patch adds the lock preempt support. Note: The current model stores lock enforcement information as separate xattr on disk. There is another effort going in parallel to store this in stat(x) of the file. This patch is self sufficient to add fencing support. Based on the availability of the stat(x) support either I will rebase this patch or we can modify the necessary bits post merging this patch. Change-Id: If4a42f3e0afaee1f66cdb0360ad4e0c005b5b017 updates: #466 Signed-off-by: Susant Palai <spalai@redhat.com>
* core: Resolve memory leak for brickMohit Agrawal2019-01-161-0/+3
| | | | | | | | | | | Problem: Some functions are not freeing memory allocated by xdr_to_genric so it has become leak Solution: Call free to avoid leak Change-Id: I3524fe2831d1511d378a032f21467edae3850314 fixes: bz#1656682 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* features/index: Correct incorrect definition in headerVijay Bellur2019-01-111-2/+2
| | | | | | | | | s/QUIESCE/INDEX/ fixes: bz#1665363 Change-Id: I6dc4fde682cedeaa10d870267b8909af1a9449c0 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
* fix 32-bit-build-smoke warningsIraj Jamali2019-01-112-2/+3
| | | | | | | fixes: bz#1622665 Change-Id: I777d67b1b62c284c62a02277238ad7538eef001e Signed-off-by: Iraj Jamali <ijamali@redhat.com>
* features/shard: Fix launch of multiple synctasks for background deletionKrutika Dhananjay2019-01-112-71/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PROBLEM: When multiple sharded files are deleted in quick succession, multiple issues were observed: 1. misleading logs corresponding to a sharded file where while one log message said the shards corresponding to the file were deleted successfully, this was followed by multiple logs suggesting the very same operation failed. This was because of multiple synctasks attempting to clean up shards of the same file and only one of them succeeding (the one that gets ENTRYLK successfully), and the rest of them logging failure. 2. multiple synctasks to do background deletion would be launched, one for each deleted file but all of them could readdir entries from .remove_me at the same time could potentially contend for ENTRYLK on .shard for each of the entry names. This is undesirable and wasteful. FIX: Background deletion will now follow a state machine. In the event that there are multiple attempts to launch synctask for background deletion, one for each file deleted, only the first task is launched. And if while this task is doing the cleanup, more attempts are made to delete other files, the state of the synctask is adjusted so that it restarts the crawl even after reaching end-of-directory to pick up any files it may have missed in the previous iteration. This patch also fixes uninitialized lk-owner during syncop_entrylk() which was leading to multiple background deletion synctasks entering the critical section at the same time and leading to illegal memory access of base inode in the second syntcask after it was destroyed post shard deletion by the first synctask. Change-Id: Ib33773d27fb4be463c7a8a5a6a4b63689705324e updates: bz#1662368 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* features/locks: Dump connection_id even for posix locksKrutika Dhananjay2019-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | ... in statedump for a better debugging experience. BEFORE: posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 13635, owner=2dd2c3a11706dc8c, client=0x7f159012b000, connection-id=(null), granted at 2018-12-31 14:20:42 connection-id is null above. AFTER: posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 10977, owner=b485e33df21bdaa2, client=0x7fa24c01ab90, connection-id=CTX_ID:68e12340-eed2-4386-bf5e-1f43cf8693d9-GRAPH_ID:0- PID:10901-HOST:dhcp35-215.lab.eng.blr.redhat.com-PC_NAME:patchy-client-0- RECON_NO:-0, granted at 2018-12-31 14:33:50 Change-Id: I4608994bacabb558a3be8c1634ee6b1d2d3022e2 fixes: bz#1662679 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* features/shard: Assign fop id during background deletion to prevent ↵Krutika Dhananjay2019-01-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | excessive logging ... of the kind "[2018-12-26 05:22:44.195019] E [MSGID: 133010] [shard.c:2253:shard_common_lookup_shards_cbk] 0-volume1-shard: Lookup on shard 785 failed. Base file gfid = cd938e64-bf06-476f-a5d4-d580a0d37416 [No such file or directory]" shard_common_lookup_shards_cbk() has a specific check to ignore ENOENT error without logging them during specific fops. But because background deletion is done in a new frame (with local->fop being GF_FOP_NULL), the ENOENT check is skipped and the absence of shards gets logged everytime. To fix this, local->fop is initialized to GF_FOP_UNLINK during background deletion. Change-Id: I0ca8d3b3bfbcd354b4a555eee520eb0479bcda35 updates: bz#1662368 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* features/bit-rot: do not send version and signature keys in dictRaghavendra Bhat2019-01-082-10/+53
| | | | | | | | | | | In lookup, if the file has been marked as bad, then bit-rot-stub was sending the version and signature xattr values as well in the response dictinary. This is not needed. Only bad file marker has to be sent. Change-Id: Id59c02e9857577c60849fd28ef657f71e0b15207 fixes: bz#1664122 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* gfapi: update returned/callback pre/post attributes to glfs_statShyamsundarR2019-01-071-2/+4
| | | | | | | Change-Id: Ie0fe971e694101aa011d66aa496d0644669c2c5a Updates: #389 Signed-off-by: Kinglong Mee <mijinlong@open-fs.com> Signed-off-by: ShyamsundarR <srangana@redhat.com>
* leases: Reset lease_ctx->timer post deletionSoumya Koduri2019-01-071-0/+1
| | | | | | | | | To avoid use_after_free, reset lease_ctx->timer back to NULL after the structure has been freed. Change-Id: Icd213ec809b8af934afdb519c335a4680a1d6cdc updates: bz#1648768 Signed-off-by: Soumya Koduri <skoduri@redhat.com>
* multiple-files: clang-scan fixesAmar Tumballi2018-12-312-0/+7
| | | | | | updates: bz#1622665 Change-Id: I9f3a75ed9be3d90f37843a140563c356830ef945 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* barrier: replace boolean-switch statement with if/elseNiels de Vos2018-12-281-43/+23
| | | | | | | | | | | | | | | | | | | | | | Squash some ugly warnings, and make the code a little bit simpler by removing some unneeded goto jumps. On Ubuntu 16.04 the following warnings were reported by Amudhan: CC barrier.lo barrier.c: In function ‘notify’: barrier.c:499:33: warning: switch condition has boolean value [-Wswitch-bool] switch (past) { ^ barrier.c: In function ‘reconfigure’: barrier.c:565:25: warning: switch condition has boolean value [-Wswitch-bool] switch (past) { ^ Change-Id: Ifb6b75058dff8c789b729c76530a1358d391f4d1 Updates: bz#1193929 Reported-by: Amudhan P <amudhan83@gmail.com> Signed-off-by: Niels de Vos <ndevos@redhat.com>
* all: handle USE_AFTER_FREE warningsAmar Tumballi2018-12-201-8/+8
| | | | | | | | | | | | | | | | | | | * we shouldn't be using 'local' after DHT_STACK_UNWIND() as it frees the content of local. Add a 'goto out' or similar logic to handle the situation. * fix possible overlook of unref(dict), instead of unref(xdata). * make coverity happy by re-ordering unref in meta-defaults. * gfid-access: re-order dictionary allocation so we don't have to do a extra unref. * other obvious errors reported. updates: bz#789278 Change-Id: If05961ee946b0c4868df19861d7e4a927a2a2489 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* posix: use synctask for janitorPoornima G2018-12-191-3/+3
| | | | | | | | | | | | | | With brick mux, the number of threads increases as the number of bricks increases. As an initiative to reduce the number of threads in brick mux scenario, replacing janitor thread to use synctask infra. Now close() and closedir() handle by separate janitor thread which is linked with glusterfs_ctx. Updates #475 Change-Id: I0c4aaf728125ab7264442fde59f3d08542785f73 Signed-off-by: Poornima G <pgurusid@redhat.com>
* Don't depend on string options to be valid alwaysPranith Kumar K2018-12-173-7/+17
| | | | | | updates bz#1650403 Change-Id: Ib5a11e691599ce4bd93c1ed5aca6060592893961 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* features/snapview-client: access priv->path inside lockRaghavendra Bhat2018-12-173-75/+360
| | | | | | | | | | To handle the race condition of a fop or a function accessing priv->path and a reconfigure changing priv->path (because entry point directory changed), the private structure's path is guarded by the lock. updates bz#1650403 Change-Id: I61c539da06d68d38eafcf2155699c7702f31323e Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* locks: handle "clear locks" xattr in fgetxattr tooCsaba Henk2018-12-143-50/+82
| | | | | | | | | | | | | | The lock clearing procedure was kicked in only in getxattr context. We need it to work the same way if it's triggered via fgetxattr (as is the case with interrupt handling). Also cleaned up the instrumentation a bit (more logs, proper management of allocated data). updates: #465 Change-Id: Icfca26ee181da3b8e15ca3fcf61cd5702e2730c8 Signed-off-by: Csaba Henk <csaba@redhat.com>
* Multiple posix related files: several modificationsYaniv Kaul2018-12-146-232/+169
| | | | | | | | | | | | | | | | | | | | | | | | Just looked at posix.c and related code and performed some changes and cleanups. The only important one is #3 below, but surely the others (#2 and #4) need careful review. Changes to other files are as they were related to code paths in posix.c. I'll send a separate patch for other posix related files. Main changes: 1. Proper initializtion for parameters, where it made sense. 2. Logged outside the lock in several places. 3. Moved from CALLOC to MALLOC where it made sense. 4. Aligned structures. 5. moved dictionary functions to use _sizen where possible. (dict_get() -> dict_get_sizen() for example) Compile-tested only! Change-Id: Ia84699fb495e06d095339c91c1ba770d1393bb6c updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* clang: Fix various missing checks for empty listShyamsundarR2018-12-145-92/+132
| | | | | | | | | | | | | | | | | | | | When using list_for_each_entry(_safe) functions, care needs to be taken that the list passed in are not empty, as these functions are not empty list safe. clag scan reported various points where this this pattern could be caught, and this patch fixes the same. Additionally the following changes are present in this patch, - Added an explicit op_ret setting in error case in the macro MAKE_INODE_HANDLE to address another clang issue reported - Minor refactoring of some functions in quota code, to address possible allocation failures in certain functions (which in turn cause possible empty lists to be passed around) Change-Id: I1e761a8d218708f714effb56fa643df2a3ea2cc7 Updates: bz#1622665 Signed-off-by: ShyamsundarR <srangana@redhat.com>
* all: remove code which is not being considered in buildAmar Tumballi2018-12-1326-8551/+0
| | | | | | | | | | | | | | | | | | | | | | | | | These xlators are now removed from build as per discussion/announcement done at https://lists.gluster.org/pipermail/gluster-users/2018-July/034400.html * move rot-13 to playground, as it is used only as demo purpose, and is documented in many places. * Removed code of below xlators: - cluster/stripe - cluster/tier - features/changetimerecorder - features/glupy - performance/symlink-cache - encryption/crypt - storage/bd - experimental/posix2 - experimental/dht2 - experimental/fdl - experimental/jbr updates: bz#1635688 Change-Id: I1d2d63c32535e149bc8dcb2daa76236c707996e8 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* xlator: make 'xlator_api' mandatoryAmar Tumballi2018-12-1310-20/+110
| | | | | | | | | | | | | | * 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>
* [geo-rep]: Worker still ACTIVE after killing bricksMohit Agrawal2018-12-137-40/+211
| | | | | | | | | | | | | | | | | | | | | | | Problem: In changelog xlator after destroying listener it call's unlink to delete changelog socket file but socket file reference is not cleaned up from process memory Solution: 1) To cleanup reference completely from process memory serialize transport cleanup for changelog and then unlink socket file 2) Brick xlator will notify GF_EVENT_PARENT_DOWN to next xlator only after cleanup all xprts Test: To test the same run below steps 1) Setup some volume and enable brick mux 2) kill anyone brick with gf_attach 3) check changelog socket for specific to killed brick in lsof, it should cleanup completely fixes: bz#1600145 Change-Id: Iba06cbf77d8a87b34a60fce50f6d8c0d427fa491 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* copy_file_range support in GlusterFSRaghavendra Bhat2018-12-124-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * libglusterfs changes to add new fop * Fuse changes: - Changes in fuse bridge xlator to receive and send responses * posix changes to perform the op on the backend filesystem * protocol and rpc changes for sending and receiving the fop * gfapi changes for performing the fop * tools: glfs-copy-file-range tool for testing copy_file_range fop - Although, copy_file_range support has been added to the upstream fuse kernel module, no release has been made yet of a kernel which contains the support. It is expected to come in the upcoming release of linux-4.20 So, as of now, executing copy_file_range fop on a fused based filesystem results in fuse kernel module sending read on the source fd and write on the destination fd. Therefore a small gfapi based tool has been written to be able test the copy_file_range fop. This tool is similar (in functionality) to the example program given in copy_file_range man page. So, running regular copy_file_range on a fuse mount point and running gfapi based glfs-copy-file-range tool gives some idea about how fast, the copy_file_range (or reflink) can be. On the local machine this was the result obtained. mount -t glusterfs workstation:new /mnt/glusterfs [root@workstation ~]# cd /mnt/glusterfs/ [root@workstation glusterfs]# ls file [root@workstation glusterfs]# cd [root@workstation ~]# time /tmp/a.out /mnt/glusterfs/file /mnt/glusterfs/new real 0m6.495s user 0m0.000s sys 0m1.439s [root@workstation ~]# time glfs-copy-file-range $(hostname) new /tmp/glfs.log /file /rrr OPEN_SRC: opening /file is success OPEN_DST: opening /rrr is success FSTAT_SRC: fstat on /rrr is success copy_file_range successful real 0m0.309s user 0m0.039s sys 0m0.017s This tool needs following arguments 1) hostname 2) volume name 3) log file path 4) source file path (relative to the gluster volume root) 5) destination file path (relative to the gluster volume root) "glfs-copy-file-range <hostname> <volume> <log file path> <source> <destination>" - Added a testcase as well to run glfs-copy-file-range tool * io-stats changes to capture the fop for profiling * NOTE: - Added conditional check to see whether the copy_file_range syscall is available or not. If not, then return ENOSYS. - Added conditional check for kernel minor version in fuse_kernel.h and fuse-bridge while referring to copy_file_range. And the kernel minor version is kept as it is. i.e. 24. Increment it in future when there is a kernel release which contains the support for copy_file_range fop in fuse kernel module. * The document which contains a writeup on this enhancement can be found at https://docs.google.com/document/d/1BSILbXr_knynNwxSyyu503JoTz5QFM_4suNIh2WwrSc/edit Change-Id: I280069c814dd21ce6ec3be00a884fc24ab692367 updates: #536 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* write-behind/bit-rot: fix identifierrishubhjain2018-12-111-1/+1
| | | | | | | | | Rename the identifiers, bit-rot-server to bit-rot in bit-rot.c & write-ahead to write-behind in write-behind.c to ensure GD2 understands the options Change-Id: Id271ae97de2e54f4e30174482c4e1fb6afc728d3 Fixes: #164 Signed-off-by: rishubhjain <rishubhjain47@gmail.com>
* New xlator option to control enable/disable of xlators in Gd2Aravinda VK2018-12-071-0/+8
| | | | | | | | | | | | | Since glusterd2 don't maintain the xlator option details in code, it directly reads the xlators options table from `*.so` files. To support enable and disable of xlator new option added to the option table with the name same as xlator name itself. This change will not affect the functionality with glusterd1. Change-Id: I23d9e537f3f422de72ddb353484466d3519de0c1 updates: #302 Signed-off-by: Aravinda VK <avishwan@redhat.com>
* all: add xlator_api to many translatorsAmar Tumballi2018-12-0618-9/+255
| | | | | | Fixes: #164 Change-Id: I93ad6f0232a1dc534df099059f69951e1339086f Signed-off-by: Amar Tumballi <amarts@redhat.com>
* libglusterfs: Move devel headers under glusterfs directoryShyamsundarR2018-12-05146-423/+423
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* features/bitrot: compare the signature with proper lengthRaghavendra Bhat2018-12-031-1/+3
| | | | | | | | | | | | | | | | | | | | | * The scrubber was comparing the checksum of the file that it calculated (by reading the file) with the on disk signature (stored via xattr) wrongly. It was using strlen to calculate the signature, while the actual length of the signature is given by the brick. Just use the actual length that the brick provides instead of trying to calculate the signature length via strlen API. * In posix, gfid2path was using the same string that contains the list of all the xattrs of file to save the value of the gfid2path xattr as well. This causes confusion when gfid2path xattr is queried by scrubber for getting the actual path of a corrupted file. Use separate string to fetch the value of the xattr instead of the string that contains the list of xattrs. Change-Id: I2d664ab524d2b312233476cb35863dde3122e9a9 fixes: bz#1654805 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* leases: Do not conflict with internal fopsSoumya Koduri2018-12-031-0/+11
| | | | | | | | | | | | | | Internal fops (with frame->root->pid < 0) are used to heal or move data and maintains data integrity. That is they do not modify client data which holds the lease. Hence no need to recall Lease for such fops. Note: Like for locks, we would need rebalance and self-heal daemon process to heal lease state as well. Change-Id: I8988693fef8d00e17c19dcc842e2238f9eb5ab48 updates: bz#1648768 Signed-off-by: Soumya Koduri <skoduri@redhat.com>
* Multiple xlator .h files: remove unused private gf_* memory types.Yaniv Kaul2018-11-305-6/+6
| | | | | | | | | | | | | It seems there were quite a few unused enums (that in turn cause unndeeded memory allocation) in some xlators. I've removed them, hopefully not causing any damage. Compile-tested only! updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I8252bd763dc1506e2d922496d896cd2fc0886ea7
* clang: Fix clang warnings in snapview-server.cShyamsundarR2018-11-291-12/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* coverity: Fix coverity issuesMohammed Rafi KC2018-11-261-0/+1
| | | | | | | | | | | | | | | | This patch fixes coverity CID : 1356537 https://scan6.coverity.com/reports.htm#v42907/p10714/fileInstanceId=87389108&defectInstanceId=26791927&mergedDefectId=1356537 CID : 1395666 https://scan6.coverity.com/reports.htm#v42907/p10714/fileInstanceId=87389187&defectInstanceId=26791932&mergedDefectId=1395666 CID : 1351707 https://scan6.coverity.com/reports.htm#v42907/p10714/fileInstanceId=87389027&defectInstanceId=26791973&mergedDefectId=1351707 CID : 1396910 https://scan6.coverity.com/reports.htm#v42907/p10714/fileInstanceId=87389027&defectInstanceId=26791973&mergedDefectId=13596910 Change-Id: I8094981a741f4d61b083c05a98df23dcf5b022a2 updates: bz#789278 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* features/changelog: Fix dictionary-leakPranith Kumar K2018-11-231-5/+0
| | | | | | | | | | rpcsvc_transport_unix_options_build() allocates the dictionary and sets it in the options variable, there is no need to allocate it before passing to the function in changelog_rpc_server_init() updates bz#1650403 Change-Id: I5b4caedba6bda706dee723a2be34c3981bf971fb Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* snapview-server: close the gfapi handle present in a forgotten inodeRaghavendra Bhat2018-11-201-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/locks: Move logging outside of a locked regionVijay Bellur2018-11-191-3/+3
| | | | | | | | | | | | In pl_metalk(), logging was being done in a synchronized region. Moving the log out of the synchronized region to avoid other threads from being blocked on the lock. Thanks to Yaniv Kaul for pointing this out. Change-Id: I0cb39fb23ae7c798ca9c42c390500491aa8e622b updates: bz#1644758 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
* lease: Treat unlk request as noop if lease not foundSoumya Koduri2018-11-171-2/+14
| | | | | | | | | | | | | | | | When the glusterfs server recalls the lease, it expects client to flush data and unlock the lease. If not it sets a timer (starting from the time it sends RECALL request) and post timeout, it revokes it. Here we could have a race where in client did send UNLK lease request but because of network delay it may have reached after server revokes it. To handle such situations, treat such requests as noop and return sucesss. Change-Id: I166402d10273f4f115ff04030ecbc14676a01663 updates: bz#1648768 Signed-off-by: Soumya Koduri <skoduri@redhat.com>
* leases: Fix incorrect inode_ref/unrefsSoumya Koduri2018-11-172-3/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From testing & code-reading, found couple of places where we incorrectly unref the inode resulting in use_after_free crash or ref leaks. This patch addresses couple of them. a) When we try to grant the very first lease for a inode, inode_ref is taken in __add_lease. This ref should be active till all the leases granted to that inode are released (i.e, till lease_cnt > 0). In addition even after lease_cnt becomes '0', the inode should be active till all the blocked fops are resumed. Hence release this ref, after resuming all those fops. To avoid granting new leases while resuming those fops, defined a new boolean (blocked_fops_resuming) to flag it in the lease_ctx. b) 'new_lease_inode' which creates new lease_inode_entry and takes ref on inode, is used while adding that entry to client_list and recall_list. Use its counter function '__destroy_lease_inode' which does unref while removing those entries from those lists. c) inode ref is also taken when added to timer->data. Unref the same after processing timer->data. Change-Id: Ie77c78ff4a971e0d9a66178597fb34faf39205fb updates: bz#1648768 Signed-off-by: Soumya Koduri <skoduri@redhat.com>
* feature/shard: Fix coverity issue - Use after freeSusant Palai2018-11-141-1/+1
| | | | | | | | CID: 1325524 Change-Id: Ic713285bd9e76d8e4dc1815aa471087d279008b5 updates: bz#789278 Signed-off-by: Susant Palai <spalai@redhat.com>
* quiesce : fix coverity issueSunny Kumar2018-11-121-0/+5
| | | | | | | | | This patch fixes 1388996 : Dereference null return value updates: bz#789278 Change-Id: I9351ae43736efd2f9abe4e1888dba89b6b3e1fe3 Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
* features/changelog: Avoid a potential null dereferenceVijay Bellur2018-11-121-4/+6
| | | | | | | | Addresses CID 1396292 Change-Id: I9141502a12fb3e18c04d07c79da87a5ebb2cfc23 updates: bz#789278 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
generated by cgit (git 2.34.1) at 2024-04-24 05:54:53 +0000