summaryrefslogtreecommitdiffstats
path: root/xlators
Commit message (Collapse)AuthorAgeFilesLines
* md-cache: avoid clearing cache when not necessaryXavi Hernandez2020-04-161-72/+93
| | | | | | | | | | | | mdc_inode_xatt_set() blindly cleared current cache when dict was not NULL, even if there was no xattr requested. This patch fixes this by only calling mdc_inode_xatt_set() when we have explicitly requested something to cache. Change-Id: Idc91a4693f1ff39f7059acde26682ccc361b947d Fixes: #1140 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* posix: fix GF_VALIDATE_OR_GOTO(this->name, this, out)Sanju Rakonde2020-04-161-3/+1
| | | | | | | | | | | | | | | Remove GF_VALIDATE_OR_GOTO(this->name, this, out) when this is passed as an argument and is checked for NULL in the caller itself. GF_VALIDATE_OR_GOTO(this->name, this, out) is modified to use xlator name instead of this->name as we are still verifying whether this is NULL. updates: #1000 Change-Id: Ide3180da29d0d4a35b2c5b9a7604fdf2ff4a9ffb Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
* mgmt/glusterd: use stat() syscall wrapperDmitry Antipov2020-04-131-2/+3
| | | | | | | | | | | | | | | Found with 0-symbol-check.t: ./tests/basic/0symbol-check.t .. 1..2 ./xlators/mgmt/glusterd/src/.libs/glusterd_la-glusterd-volume-set.o should call sys_stat, not stat ok 1 [ 40/ 41011] < 40> 'find . -name *.o -exec ./tests/basic/symbol-check.sh {} \;' not ok 2 [ 11/ 1] < 42> '[ ! -e ./.symbol-check-errors ]' -> '' Failed 1/2 subtests Change-Id: I8962f487cd88738a1f7a962049d513712687088c Fixes: #1160 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
* protocol/server: Fix coverity issue RESOURCE_LEAKSheetal Pamecha2020-04-101-0/+1
| | | | | | | | | Handle case of arg not freed CID: 1422174 Updates: #1060 Change-Id: Ibd03908a3ea8369035c2b7f6e024b3e5be48f436 Signed-off-by: Sheetal Pamecha <spamecha@redhat.com>
* posix: Avoid dict_del logs in posix_is_layout_stale while key is NULLMohit Agrawal2020-04-091-2/+3
| | | | | | | | | | | | Problem: The key "GF_PREOP_PARENT_KEY" has been populated by dht and for non-distribute volume like 1x3 key is not populated so posix_is_layout stale throw a message while a file is created Solution: To avoid a log put a condition before delete a key Change-Id: I813ee7960633e7f9f5e9ad2f42f288053d9eb71f Fixes: #1150 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* mount/fuse: Wait for 'mount' child to exit before dyingPranith Kumar K2020-04-091-0/+27
| | | | | | | | | | | | | | | | Problem: tests/bugs/protocol/bug-1433815-auth-allow.t fails sometimes because of stale mount. This stale mount comes into picture when parent process dies without waiting for the child process which mounts fuse fs to die Fix: Wait for mounting child process to die before dying. Fixes: #1152 Change-Id: I8baee8720e88614fdb762ea822d5877973eef8dc Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* dht - fixing a permission update issueBarak Sason Rofman2020-04-083-18/+39
| | | | | | | | | | | | | | | | | | When bringing back a downed brick and performing lookup from the client side, the permission on said brick aren't updated on the first lookup, but only on the second. This patch modifies permission update logic so the first lookup will trigger a permission update on the downed brick. LIMITATIONS OF THE PATCH: As the choice of source depends on whether the directory has layout or not. Even the directories on the newly added brick will have layout xattr[zeroed], but the same is not true for a root directory. Hence, in case in the entire cluster only the newly added bricks are up [and others are down], then any change in permission during this time will be overwritten by the older permissions when the cluster is restarted. fixes: #999 Change-Id: Ieb70246d41e59f9cae9f70bc203627a433dfbd33 Signed-off-by: Barak Sason Rofman <bsasonro@redhat.com>
* cluster/afr: Removing unsupported options from code base to improve coveragekarthik-us2020-04-071-9/+0
| | | | | | | | | | | | | | | | Support for gluster volume heal <volname> info healed/heal-failed was removed by commit bb02cfb56ae08f56df4452c2b948fa962ae1212b in release-3.6. cli parser will display the usage message in all the supported versions whenever these clis are run, leading to some dead code in the latest branches. Since support for these clis were removed long back, this should not give any backward compatibility issues as well. Hence removing the dead code from the code base which will lead to better code coverage by the regression runs as well. Updates: #1052 Change-Id: I0c2b061469caf233c06d9699b0d159ce48e240b9 Signed-off-by: karthik-us <ksubrahm@redhat.com>
* Posix: Optimize posix code to improve file creationMohit Agrawal2020-04-065-74/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Before executing a fop in POSIX xlator it builds an internal path based on GFID.To validate the path it call's (l)stat system call and while .glusterfs is heavily loaded kernel takes time to lookup inode and due to that performance drops Solution: In this patch we followed two ways to improve the performance. 1) Keep open fd specific to first level directory(gfid[0]) in .glusterfs, it would force to kernel keep the inodes from all those files in cache. In case of memory pressure kernel won't uncache first level inodes. We need to open 256 fd's per brick to access the entry faster. 2) Use at based call's to access relative path to reduce path based lookup time. Note: To verify the patch we have executed kernel untar 100 times on 6 different clients after enabling metadata group-cache and some other option.We were getting more than 20 percent improvement in kenel untar after applying the patch. Credits: Xavi Hernandez <xhernandez@redhat.com> Change-Id: I1643e6b01ed669b2bb148d02f4e6a8e08da45343 updates: #891 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* mgmt/glusterd: Reduce log level of repetitive logVijay Bellur2020-04-061-1/+1
| | | | | | | | | | | | | | | Noticed that the following message repeats quite a bit in log files when an external monitoring tool queries gluster for list of volumes periodically: "Received get vol req" As there's not much value in having this log message at log level INFO, changing the log level to DEBUG to make glusterd.log a bit quieter. Change-Id: I4e791fc65b9a4f813d295e7b2b6a05f3c0782e69 Updates: #1000 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
* storage/posix: log the ENOENT errors in posix_pstatRaghavendra Bhat2020-04-041-0/+5
| | | | | | Change-Id: I93f11dae6e4939ab79b0481ead2a4f7bb3085b70 Fixes: #1142 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
* write-behind: fix data corruptionXavi Hernandez2020-04-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a bug in write-behind that allowed a previous completed write to overwrite the overlapping region of data from a future write. Suppose we want to send three writes (W1, W2 and W3). W1 and W2 are sequential, and W3 writes at the same offset of W2: W2.offset = W3.offset = W1.offset + W1.size Both W1 and W2 are sent in parallel. W3 is only sent after W2 completes. So W3 should *always* overwrite the overlapping part of W2. Suppose write-behind processes the requests from 2 concurrent threads: Thread 1 Thread 2 <received W1> <received W2> wb_enqueue_tempted(W1) /* W1 is assigned gen X */ wb_enqueue_tempted(W2) /* W2 is assigned gen X */ wb_process_queue() __wb_preprocess_winds() /* W1 and W2 are sequential and all * other requisites are met to merge * both requests. */ __wb_collapse_small_writes(W1, W2) __wb_fulfill_request(W2) __wb_pick_unwinds() -> W2 /* In this case, since the request is * already fulfilled, wb_inode->gen * is not updated. */ wb_do_unwinds() STACK_UNWIND(W2) /* The application has received the * result of W2, so it can send W3. */ <received W3> wb_enqueue_tempted(W3) /* W3 is assigned gen X */ wb_process_queue() /* Here we have W1 (which contains * the conflicting W2) and W3 with * same gen, so they are interpreted * as concurrent writes that do not * conflict. */ __wb_pick_winds() -> W3 wb_do_winds() STACK_WIND(W3) wb_process_queue() /* Eventually W1 will be * ready to be sent */ __wb_pick_winds() -> W1 __wb_pick_unwinds() -> W1 /* Here wb_inode->gen is * incremented. */ wb_do_unwinds() STACK_UNWIND(W1) wb_do_winds() STACK_WIND(W1) So, as we can see, W3 is sent before W1, which shouldn't happen. The problem is that wb_inode->gen is only incremented for requests that have not been fulfilled but, after a merge, the request is marked as fulfilled even though it has not been sent to the brick. This allows that future requests are assigned to the same generation, which could be internally reordered. Solution: Increment wb_inode->gen before any unwind, even if it's for a fulfilled request. Special thanks to Stefan Ring for writing a reproducer that has been crucial to identify the issue. Change-Id: Id4ab0f294a09aca9a863ecaeef8856474662ab45 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: #884
* features/utime: Don't access frame after stack-windPranith Kumar K2020-04-031-15/+20
| | | | | | | | | | | | | Problem: frame is accessed after stack-wind. This can lead to crash if the cbk frees the frame. Fix: Use new frame for the wind instead. Updates: #832 Change-Id: I64754609f1114b0bbd4d1336fa81a56f2cca6e03 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* afr: mark pending xattrs as a part of metadata healRavishankar N2020-04-021-1/+61
| | | | | | | | | | | | | | | | | | | ...if pending xattrs are zero for all children. Problem: If there are no pending xattrs and a metadata heal needs to be performed, it can be possible that we end up with xattrs inadvertendly deleted from all bricks, as explained in the BZ. Fix: After picking one among the sources as the good copy, mark pending xattrs on all sources to blame the sinks. Now even if this metadata heal fails midway, a subsequent heal will still choose one of the valid sources that it picked previously. Fixes: #1067 Change-Id: If1b050b70b0ad911e162c04db4d89b263e2b8d7b Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* add clean local after grant lockl17zhou2020-04-011-7/+8
| | | | | | | | | found by flock test, without correct ref number of fd, lock will not be correctly released. Fixes: bz#1779089 Change-Id: I3e466b17c852eb219c8778e43af8ad670a8449cc Signed-off-by: l17zhou <cynthia.zhou@nokia-sbell.com>
* Marker: Logically deadcode found by coverityHari Gowtham2020-03-311-15/+11
| | | | | | | | Have removed the deadcode found by the coverity id:1356503 Change-Id: Ieaa41e864538fb82dc967b4a214d4db09e267098 Updates: #1060 Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
* core[brick_mux]: brick crashed when creating and deleting volumes over timeMohit Agrawal2020-03-276-9/+79
| | | | | | | | | | | | | | | | | Problem: In brick_mux environment, while volumes are created/stopped in a loop after running a long time the main brick is crashed.The brick is crashed because the main brick process was not cleaned up memory for all objects at the time of detaching a volume. Below are the objects that are missed at the time of detaching a volume 1) xlator object for a brick graph 2) local_pool for posix_lock xlator 3) rpc object cleanup at quota xlator 4) inode leak at brick xlator Solution: To avoid the crash resolve all leak at the time of detaching a brick Change-Id: Ibb6e46c5fba22b9441a88cbaf6b3278823235913 updates: #977 Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
* features/shard: Fix crash during shards cleanup in error casesKrutika Dhananjay2020-03-261-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | A crash is seen during a reattempt to clean up shards in background upon remount. And this happens even on remount (which means a remount is no workaround for the crash). In such a situation, the in-memory base inode object will not be existent (new process, non-existent base shard). So local->resolver_base_inode will be NULL. In the event of an error (in this case, of space running out), the process would crash at the time of logging the error in the following line - gf_msg(this->name, GF_LOG_ERROR, local->op_errno, SHARD_MSG_FOP_FAILED, "failed to delete shards of %s", uuid_utoa(local->resolver_base_inode->gfid)); Fixed that by using local->base_gfid as the source of gfid when local->resolver_base_inode is NULL. Change-Id: I0b49f2b58becd0d8874b3d4b14ff8d92a89d02d5 Fixes: #1127 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* dht: gf_defrag_process_dir is called even if gf_defrag_fix_layout has failedSusant Palai2020-03-241-0/+1
| | | | | | | | | Currently even though gf_defrag_fix_layout fails with ENOENT or ESTALE, a subsequent call is made to gf_defrag_process_dir leading to rebalance failure. fixes: #1102 Change-Id: Ib0c309fd78e89a000fed3feb4bbe2c5b48e61478 Signed-off-by: Susant Palai <spalai@redhat.com>
* worm-xlator: fix newly introduced coverity issueSunny Kumar2020-03-201-4/+0
| | | | | | | | | This patch fixes CID: 1420405 updates: #1060 Change-Id: I0524e999fa1d36ed5a713eabf65482c04ad43a1a Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
* Posix: Use simple approach to close fdMohit Agrawal2020-03-204-127/+6
| | | | | | | | | | | | | | | Problem: posix_release(dir) functions add the fd's into a ctx->janitor_fds and janitor thread closes the fd's.In brick_mux environment it is difficult to handle race condition in janitor threads because brick spawns a single janitor thread for all bricks. Solution: Use synctask to execute posix_release(dir) functions instead of using background a thread to close fds. Credits: Pranith Karampuri <pkarampu@redhat.com> Change-Id: Iffb031f0695a7da83d5a2f6bac8863dad225317e Fixes: bz#1811631 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* WORM-Xlator: Initial write of a file succeeds if auto-commit-period 0David Spisla2020-03-171-17/+60
| | | | | | | | | | | | | | | | | | | If worm-file-level enabled and auto-commit-period 0 an initial write of a file (e.g. $ echo test >> file1.txt) would lead to an zero byte file because the WORM xlator immediately WORMed the file when it was created. To avoid this we move the setting of trusted.worm_file from worm_create_cbk to worm_release . This means that this xattr will set when the filehandle is closed and all initial WRITE FOPs succeed. Finally we also perform gf_worm_state_transition in worm_release to ensure that the file will be immediately WORMed after the file handle was closed. Change-Id: I5d02e18975b646ca1a27ed41d836e9d0dc333204 Fixes: bz#1808421 Signed-off-by: David Spisla <david.spisla@iternity.com>
* open-behind: fix missing fd referenceXavi Hernandez2020-03-171-11/+16
| | | | | | | | | | | Open behind was not keeping any reference on fd's pending to be opened. This makes it possible that a concurrent close and en entry fop (unlink, rename, ...) caused destruction of the fd while it was still being used. Change-Id: Ie9e992902cf2cd7be4af1f8b4e57af9bd6afd8e9 Fixes: bz#1810934 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* cluster/afr: Fixes for haloPranith Kumar K2020-03-133-5/+19
| | | | | | | | | | | Current implementation assumes that ping-event will come after connect event but that may not be the case in the cases where after socket connection fds need to be re-opened which would consume more time. So handle any order of the ping/child-up events. fixes: bz#1800583 Change-Id: I6bcdc0caa503bdc039ef2b4739fbf4afae121f05 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* utime: resolve an issue of permission denied logsAmar Tumballi2020-03-131-0/+10
| | | | | | | | | | | | In case where uid is not set to be 0, there are possible errors from acl xlator. So, set `uid = 0;` with pid indicating this is set from UTIME activity. The message "E [MSGID: 148002] [utime.c:146:gf_utime_set_mdata_setxattr_cbk] 0-dev_SNIP_data-utime: dict set of key for set-ctime-mdata failed [Permission denied]" repeated 2 times between [2019-12-19 21:27:55.042634] and [2019-12-19 21:27:55.047887] Change-Id: Ieadf329835a40a13ac0bf908dac776e66954466c Fixes: #832 Signed-off-by: Amar Tumballi <amar@kadalu.io>
* glusterd/snapshot: Add a warning message when a volume config changesMohammed Rafi KC2020-03-123-1/+40
| | | | | | | | | | | | While changing a volume configuration, there is a chance that the brick layout on the disk might be changed. If snapshot is present on such volumes that will effects it's working. So this patch adds a warning message if snapshot is present while a volume config change happen. Change-Id: I7256863fef734841fce0bc9ad94d5d201b1813d5 Fixes: bz#1812144 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* dht - selfheal code cleaningBarak Sason Rofman2020-03-121-135/+20
| | | | | | | | | 1 - Converted methods to static 2 - Removed unused code Change-Id: I49db3e28116da1c3c9ff0a33dcce7281bc3856f7 updates: bz#1193929 Signed-off-by: Barak Sason Rofman <bsasonro@redhat.com>
* protocol/client: fallback to anonymous fd for fsyncl17zhou2020-03-101-2/+4
| | | | | Change-Id: I32f801206ce7fbd05aa693f44c2f140304f2e275 Fixes: bz#1810842
* Posix: structs re-aligned and manual padding addedPurna Pavan Chandra Aekkaladevi2020-03-092-44/+52
| | | | | | | | | | | | All the structs present inside xlators/storage/posix have been re-aligned into memory efficient way. Manual padding has been added to remove compile time padding. This manual padding is for development and debugging benefits. It lets to use -Wpadded option and raise warnings from the remaining structs where compile time padding happens. Change-Id: Ie72c02810803eae29fca435c71aa131a1315b8a8 Updates: bz#1754448 Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkala@redhat.com>
* mgmt/glusterd: Adding validation for statedump pathyatipadia2020-03-091-2/+29
| | | | | | | | | | | | | | | | | | | | | | | Description of problem: server.statedump-path is the path where statedumps are stored, by default it is /var/run/gluster. And can be set to any valid directory path. It was observed that server.statedump-path was also accepting file, non-existent file and non-existent paths as well. And statedump command was successful even when statedumps with all the invalid paths. a. A file b. A non-existent path Solution: Added a validation function in gluster-volume-set.c which will allow volume set to success if it's a valid directory and in all other cases, volume set should fail. Fixes: bz#1787122 Change-Id: Ia66e2b3d35f23efc5444c829928779a79d827b42 Signed-off-by: yatipadia <ypadia@redhat.com> Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
* dht/rebalance - fixing failure occurace due to rebalance stopBarak Sason Rofman2020-03-041-0/+8
| | | | | | | | | | | | | | | | | Probelm description: When topping rebalance, the following error messages appear in the rebalance log file: [2020-01-28 14:31:42.452070] W [dht-rebalance.c:3447:gf_defrag_process_dir] 0-distrep-dht: Found error from gf_defrag_get_entry [2020-01-28 14:31:42.452764] E [MSGID: 109111] [dht-rebalance.c:3971:gf_defrag_fix_layout] 0-distrep-dht: gf_defrag_process_dir failed for directory: /0/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31 [2020-01-28 14:31:42.453498] E [MSGID: 109016] [dht-rebalance.c:3906:gf_defrag_fix_layout] 0-distrep-dht: Fix layout failed for /0/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30 In order to avoid seing these error messages, a modification to the error handling mechanism has been made. In addition, several log messages had been added in order to improve debugging efficiency fixes: bz#1800956 Change-Id: Ifc82dae79ab3da9fe22ee25088a2a6b855afcfcf Signed-off-by: Barak Sason Rofman <bsasonro@redhat.com>
* xlator/dht-helper: structure loggingyatipadia2020-03-032-97/+75
| | | | | | | | | | convert gf_msg() to gf_smsg() Updates: #657 Change-Id: Iab35ac89b7d7fb6fb0074fc61b11bf679c517c9d Signed-off-by: yatipadia <ypadia@redhat.com> Signed-off-by: yatip <ypadia@redhat.com>
* protocol/client: structure loggingyatip2020-03-036-71/+83
| | | | | | | | | convert gf_msg() to gf_smsg() Updates: #657 Change-Id: I76a09cfd283bb4ec5c4358536da66547aaf0de31 Signed-off-by: yatip <ypadia@redhat.com>
* protocol/server-helpers: structure loggingyatip2020-03-032-58/+66
| | | | | | | | | convert gf_msg() to gf_smsg() Updates: #657 Change-Id: Ic7b38b646fa0932f7c1562467866137c4567e1f1 Signed-off-by: yatip <ypadia@redhat.com>
* protocol/server-rpc-fops_v2: structure loggingyatip2020-03-032-411/+363
| | | | | | | | | convert gf_msg() to gf_smsg() Updates: #657 Change-Id: I01146bcd06bca44faeca29da48fab1ee3fc51e00 Signed-off-by: yatip <ypadia@redhat.com>
* protocol/server: structure loggingyatip2020-03-032-147/+157
| | | | | | | | Convert all gf_msg() to gf_smsg() Updates: #657 Change-Id: Ic54b03f05e2766c87f50df0b3a66803b5519fad9 Signed-off-by: yatip <ypadia@redhat.com>
* cluster/afr: fix race when bricks come upXavi Hernandez2020-03-023-6/+9
| | | | | | | | | | | | | | | | | | | | The was a problem when self-heal was sending lookups at the same time that one of the bricks was coming up. In this case there was a chance that the number of 'up' bricks changes in the middle of sending the requests to subvolumes which caused a discrepancy in the expected number of replies and the actual number of sent requests. This discrepancy caused that AFR continued executing requests before all requests were complete. Eventually, the frame of the pending request was destroyed when the operation terminated, causing a use- after-free issue when the answer was finally received. In theory the same thing could happen in the reverse way, i.e. AFR tries to wait for more replies than sent requests, causing a hang. Change-Id: I7ed6108554ca379d532efb1a29b2de8085410b70 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: bz#1808875
* xlator/dht-lock: structure loggingyatipadia2020-02-262-105/+113
| | | | | | | | convert gf_msg() to gf_smsg() Change-Id: If540ca921b1cd8ca75b92b3d72eb9eb61bdaaa10 Updates: #657 Signed-off-by: yatip <ypadia@redhat.com>
* mount.glusterfs: don't strip / from subdir-mountsAndreas Loibl2020-02-201-0/+1
| | | | | Change-Id: Ib07c31dc6669aa9d9f84a21e6160237290ed9afb Fixes: bz#1804786
* glusterd: Brick process fails to come up with brickmux onVishal Pandey2020-02-201-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue: 1- In a cluster of 3 Nodes N1, N2, N3. Create 3 volumes vol1, vol2, vol3 with 3 bricks (one from each node) 2- Set cluster.brick-multiplex on 3- Start all 3 volumes 4- Check if all bricks on a node are running on same port 5- Kill N1 6- Set performance.readdir-ahead for volumes vol1, vol2, vol3 7- Bring N1 up and check volume status 8- All bricks processes not running on N1. Root Cause - Since, There is a diff in volfile versions in N1 as compared to N2 and N3 therefore glusterd_import_friend_volume() is called. glusterd_import_friend_volume() copies the new_volinfo and deletes old_volinfo and then calls glusterd_start_bricks(). glusterd_start_bricks() looks for the volfiles and sends an rpc request to glusterfs_handle_attach(). Now, since the volinfo has been deleted by glusterd_delete_stale_volume() from priv->volumes list before glusterd_start_bricks() and glusterd_create_volfiles_and_notify_services() and glusterd_list_add_order is called after glusterd_start_bricks(), therefore the attach RPC req gets an empty volfile path and that causes the brick to crash. Fix- Call glusterd_list_add_order() and glusterd_create_volfiles_and_notify_services before glusterd_start_bricks() cal is made in glusterd_import_friend_volume Change-Id: Idfe0e8710f7eb77ca3ddfa1cabeb45b2987f41aa Fixes: bz#1773856 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* afr: prevent spurious entry heals leading to gfid split-brainRavishankar N2020-02-185-15/+7
| | | | | | | | | | | | | | | | | | | | Problem: In a hyperconverged setup with granular-entry-heal enabled, if a file is recreated while one of the bricks is down, and an index heal is triggered (with the brick still down), entry-self heal was doing a spurious heal with just the 2 good bricks. It was doing a post-op leading to removal of the filename from .glusterfs/indices/entry-changes as well as erroneous setting of afr xattrs on the parent. When the brick came up, the xattrs were cleared, resulting in the renamed file not getting healed and leading to gfid split-brain and EIO on the mount. Fix: Proceed with entry heal only when shd can connect to all bricks of the replica, just like in data and metadata heal. fixes: bz#1801624 Change-Id: I916ae26ad1fabf259bc6362da52d433b7223b17e Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* cluster/thin-arbiter: Wait for TA connection before ta-file lookupAshish Pandey2020-02-171-17/+21
| | | | | | | | | | | | | | | | | | Problem: When we mount a ta volume, as soon as 2 data bricks are connected we consider that the mount is done and then send a lookup/create on ta file on ta node. However, this connection with ta node might not have been completed. Due to this delay, ta replica id file will not be created and we will see ENOTCONN error in log file if we do lookup. Solution: As we know that this ta node could have a higher latency, we should wait for reasonable time for connection to happen before sending lookup/create on replica id file. fixes: bz#1720463 Change-Id: I36f90865afe617e4e84cee57fec832a16f5dd6cc
* dht - Reducing methods scopeBarak Sason Rofman2020-02-136-104/+60
| | | | | | | | | | 1. Reduced methods scope in the following: inode read&write, layout, linkfile, shard 2. Removed dead code @ dht-linkkile.c:174-228 & dht-shard.c:44 Change-Id: I2d08a10c7b074fccdb0c020845cad60c6ea32db5 updates: bz#1193929 Signed-off-by: Barak Sason Rofman <bsasonro@redhat.com>
* cluster/afr: Check for lock on source & sink before doing data healkarthik-us2020-02-131-3/+19
| | | | | | | | | | | | | | | | Problem: In function afr_selfheal_data_block(), we only check for the lock count to be equal to or greater than the number of sinks. There can be a case where we have 2 source bricks and one sink and the locking is successful on only the source brick(s). In this case we continue with the healing on sink without having a lock, which is not correct. Fix: Check for lock on atleast source & one sink before starting the data heal. Change-Id: Iebcb57dcaa4b31831fedfee63d6ca16e9d6c8df8 fixes: bz#1688115 Signed-off-by: karthik-us <ksubrahm@redhat.com>
* volgen: make thin-arbiter name unique in 'pending-xattr' optionAmar Tumballi2020-02-121-2/+12
| | | | | | | | | | Thin-arbiter module makes use of 'pending-xattr' name for the translator as the filename which gets created in thin-arbiter node. By making this unique, we can host single thin-arbiter node for multiple clusters. Updates: #763 Change-Id: Ib3c732e7e04e6dba229e71ae3e64f1f3cb6d794d Signed-off-by: Amar Tumballi <amar@kadalu.io>
* tests: Fix spurious self-heald.t failurePranith Kumar K2020-02-111-23/+15
| | | | | | | | | | | | | | | | | | Problem: heal-info code assumes that all indices in xattrop directory definitely need heal. There is one corner case. The very first xattrop on the file will lead to adding the gfid to 'xattrop' index in fop path and in _cbk path it is removed because the fop is zero-xattr xattrop in success case. These gfids could be read by heal-info and shown as needing heal. Fix: Check the pending flag to see if the file definitely needs or not instead of which index is being crawled at the moment. fixes: bz#1801623 Change-Id: I79f00dc7366fedbbb25ec4bec838dba3b34c7ad5 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* feature/changelog: Avoid thread creation if xlator is not enabledMohit Agrawal2020-02-094-40/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Changelog creates threads even if the changelog is not enabled Background: Changelog xlator broadly does two things 1. Journalling - Cosumers are geo-rep and glusterfind 2. Event Notification for registered events like (open, release etc) - Consumers are bitrot, geo-rep The existing option "changelog.changelog" controls journalling and there is no option to control event notification and is enabled by default. So when bitrot/geo-rep is not enabled on the volume, threads and resources(rpc and rbuf) related to event notifications consumes resources and cpu cycle which is unnecessary. Solution: The solution is to have two different options as below. 1. changelog-notification : Event notifications 2. changelog : Journalling This patch introduces the option "changelog-notification" which is not exposed to user. When either bitrot or changelog (journalling) is enabled, it internally enbales 'changelog-notification'. But once the 'changelog-notification' is enabled, it will not be disabled for the life time of the brick process even after bitrot and changelog is disabled. As of now, rpc resource cleanup has lot of races and is difficult to cleanup cleanly. If allowed, it leads to memory leaks and crashes on enable/disable of bitrot or changelog (journal) in a loop. Hence to be safer, the event notification is not disabled within lifetime of process once enabled. Change-Id: Ifd00286e0966049e8eb9f21567fe407cf11bb02a Updates: #475 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* dht: Fix stale-layout and create issueSusant Palai2020-02-096-20/+253
| | | | | | | | | | | | | | | | | Problem: With lookup-optimize set to on by default, a client with stale-layout can create a new file on a wrong subvol. This will lead to possible duplicate files if two different clients attempt to create the same file with two different layouts. Solution: Send in-memory layout to be cross checked at posix before commiting a "create". In case of a mismatch, sync the client layout with that of the server and attempt the create fop one more time. test: Manual, testcase(attached) fixes: bz#1786679 Change-Id: Ife0941f105113f1c572f4363cbcee65e0dd9bd6a Signed-off-by: Susant Palai <spalai@redhat.com>
* bitrot: Make number of signer threads configurableKotresh HR2020-02-076-21/+145
| | | | | | | | | | | | | The number of signing process threads (glfs_brpobj) is set to 4 by default. The recommendation is to set it to number of cores available. This patch makes it configurable as follows gluster vol bitrot <volname> signer-threads <count> fixes: bz#1797869 Change-Id: Ia883b3e5e34e0bc8d095243508d320c9c9c58adc Signed-off-by: Kotresh HR <khiremat@redhat.com>
* protocol/client-rpc-fops: structure loggingyatip2020-02-062-350/+278
| | | | | | | | | convert all gf_msg() to gf_smsg() Updates: #657 Change-Id: Ia9d4fb17579af6586bc13d69ec7990c6cf220aac Signed-off-by: yatip <ypadia@redhat.com>
generated by cgit (git 2.34.1) at 2024-04-30 09:54:26 +0000