summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* features/bit-rot: invalid snprintf() buffer sizerelease-7Dmitry Antipov2020-09-291-2/+2
| | | | | | | | | | | | | | | | Found with clang-10 -Wfortify-source: bit-rot-scrub.c:1802:15: warning: 'snprintf' size argument is too large; destination buffer has size 32, but size argument is 4096 [-Wfortify-source] len = snprintf(key, PATH_MAX, "quarantine-%d", j); ^ bit-rot-scrub.c:1813:9: warning: 'snprintf' size argument is too large; destination buffer has size 32, but size argument is 4096 [-Wfortify-source] snprintf(main_key, PATH_MAX, "quarantine-%d", tmp_count); Change-Id: I9b9c09ef2223ed181d81215154345de976b82f13 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Fixes: #1221
* doc: Added release 7.8 notesv7.8Rinku Kothiya2020-09-281-0/+36
| | | | | | | Fixes: #1517 Change-Id: I9bbd28ef3614fdcbce11e798a38149a5e00b75c0 Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* build: when building with tirpc, link xlators, etc., with libtirpcKaleb S. KEITHLEY2020-09-272-2/+3
| | | | | | | | | | | | | uncovered on Ubuntu Groovy (20.10, ubuntu's bleeding edge devel dist), seems to now have stricter link semantics than it did when we last built 8.1 and 7.5. Many xlators actually do have direct calls to xdr_sizeof(), so strictly speaking they should be linked with libtirpc. Change-Id: Iee1fd3528fde19db397c4eae6978d9b9a2c3e17f Updates: #1002 Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
* glusterd: readdir-ahead off by defaultnik-redhat2020-09-271-1/+1
| | | | | | | | | | | | | Changing the default value of readdir-ahead to off, but it can be enabled/disabled later on if with gluster vol set <volname> performance.readdir-ahead enabel/disable command. Updates: #1472 Change-Id: Idb3e16e8be98d7a811fc8e5d09906919ef50fbab Signed-off-by: nik-redhat <nladha@redhat.com> (cherry picked from commit 84a4cf76219b6187fc625740d1a1ebbe40e9f22c)
* open-behind: implement create fopXavi Hernandez2020-09-271-0/+52
| | | | | | | | | | | | | | Open behind didn't implement create fop. This caused that files created were not accounted for the number of open fd's. This could cause future opens to be delayed when they shouldn't. This patch implements the create fop. It also fixes a problem when destroying the stack: when frame->local was not NULL, STACK_DESTROY() tried to mem_put() it, which is not correct. Fixes: #1440 Change-Id: Ic982bad07d4af30b915d7eb1fbcef7a847a45869 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* geo-rep: Fix string comparisonShwetha K Acharya2020-09-091-1/+1
| | | | | | | | | | | | | Backport of: >Patch link: https://review.gluster.org/#/c/glusterfs/+/24865/ >Fixes: #1438 >Change-Id: If9f1c2e89e504512bcf77608fb4a4fedb19f0399 >Signed-off-by: Kotresh HR <khiremat@redhat.com> Fixes: #1438 Change-Id: If9f1c2e89e504512bcf77608fb4a4fedb19f0399 Signed-off-by: Shwetha K Acharya <sacharya@redhat.com> (cherry picked from commit 005d2ac1d8cc57e0e36f7cf230ae09a4f860bd16)
* libglusterfs: fix dict leakRavishankar N2020-09-074-10/+30
| | | | | | | | | | | | | | | Problem: gf_rev_dns_lookup_cached() allocated struct dnscache->dict if it was null but the freeing was left to the caller. Fix: Moved dict allocation and freeing into corresponding init and fini routines so that its easier for the caller to avoid such leaks. Updates: #1000 Change-Id: I90d6a6f85ca2dd4fe0ab461177aaa9ac9c1fbcf9 Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit 079f7a7d8a2bd85070c1da4dde2452ca82a1cdbb)
* glusterd: cksum mismatch on upgrading to latest glusternik-redhat2020-09-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | Issue: In gluster versions less than 7, the checksums were calculated whether or not the quota is enabled or not, and that cksum value was also getting stored in the quota.cksum file. But, from gluster 7 version onwards cksum was calculated only if the quota is enabled. Due to this, the cksums in quota.cksum files differ after upgrading. Fix: Added a check to see if the OP_VERSION is less than 7 then, follow the previous method otherwise, move as per the latest changes for cksum calculation. This changes for the cksum calculation was done in this commit : https://github.com/gluster/glusterfs/commit/3b5eb592f5 Updates: #1332 Change-Id: I7a95e5e5f4d4be4983fb7816225bf9187856c003 Signed-off-by: nik-redhat <nladha@redhat.com> (cherry picked from commit 865cca1190e233381f975ff36118f46e29477dcf) Signed-off-by: nik-redhat <nladha@redhat.com>
* afr: add null check for thin-arbiter gfid.Ravishankar N2020-08-274-88/+13
| | | | | | | | | | | | | | | | | | | | | | Problem: Lookup/creation of thin-arbiter ID file happens in background during mounting. On new volumes, if the ID file creation is in progress, and a FOP fails on data brick, a post-op (xattrop) is attemtped on TA. Since the TA file's gfid is null at this point, the ASSERT checks in protocol/ client causes a crash. Fix: Given that we decided to do Lookup/creation of thin-arbiter in background, fail the other AFR FOPS on TA if the ID file's gfid is null instead of winding it down to protocol/client. Also remove afr_changelog_thin_arbiter_post_op() which seems to be dead code. Updates: #763 Change-Id: I70dc666faf55cc5c8f7cf8e7d36085e4fa399c4d Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit f9b5074394e3d2f3b6728aab97230ba620879426)
* cluster/afr: Delay post-op for fsyncPranith Kumar K2020-08-279-10/+240
| | | | | | | | | | | | | | | | | | Problem: AFR doesn't delay post-op for fsync fop. For fsync heavy workloads this leads to un-necessary fxattrop/finodelk for every fsync leading to bad performance. Fix: Have delayed post-op for fsync. Add special flag in xdata to indicate that afr shouldn't delay post-op in cases where either the process will terminate or graph-switch would happen. Otherwise it leads to un-necessary heals when the graph-switch/process-termination happens before delayed-post-op completes. Fixes: #1253 Change-Id: I531940d13269a111c49e0510d49514dc169f4577 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* open-behind: fix call_frame leakXavi Hernandez2020-08-201-4/+10
| | | | | | | | | | | | | When an open was delayed, a copy of the frame was created because the current frame was used to unwind the "fake" open. When the open was actually sent, the frame was correctly destroyed. However if the file was closed before needing to send the open, the frame was not destroyed. This patch correctly destroys the frame in all cases. Change-Id: I8c00fc7f15545c240e8151305d9e4cf06d653926 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: #1440
* cluster/ec: Remove stale entries from indices/xattrop folderAshish Pandey2020-08-202-2/+78
| | | | | | | | | | | | | | | | | | | | Problem: If a gfid is present in indices/xattrop folder while the file/dir is actaully healthy and all the xattrs are healthy, it causes lot of lookups by shd on an entry which does not need to be healed. This whole process eats up lot of CPU usage without doing meaningful work. Solution: Set trusted.ec.dirty xattr of the entry so that actual heal process happens and at the end of it, during unset of dirty, gfid enrty from indices/xattrop will be removed. Change-Id: Ib1b9377d8dda384bba49523e9ff6ba9f0699cc1b Fixes: #1385 Signed-off-by: Ashish Pandey <aspandey@redhat.com> (cherry picked from commit ba1b0a471dec968633f89c7f790b099fb4ad700d)
* glusterd: Increase buffer length to save multiple hostnames in peer fileMohit Agrawal2020-08-191-3/+3
| | | | | | | | | | | | | | | | Problem: At the time of handling friend update request glusterd updates peer file and if DNS has returned multiple hostnames for the same IP, glusterd saves all hostnames in peer file.In commit 1fa089e7a2b180e0bdcc1e7e09a63934a2a0c0ef We changed the approach to save all key value pairs in single shot. In case of a buffer is not having space to store the hostnames glusterd writes partial hostname in peer file. Solution: To avoid the failure increase the buffer length Change-Id: Iee969d165333e9c5ba69431d474c541b8f12d442 Fixes: #1407 Signed-off-by: Mohit Agrawal <moagrawa@redhat.com> (cherry picked from commit 6e8e73a06d71382f8f6e3cd83fe72692d19e66ba)
* geo-rep: Fix corner case in rename on mkdir during hybrid crawlSunny Kumar2020-08-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The issue is being hit during hybrid mode while handling rename on slave. In this special case the rename is recorded as mkdir and geo-rep process it by resolving the path form backend. While resolving the backend path during this special handling one corner case is not considered. <snip> Traceback (most recent call last):   File "/usr/libexec/glusterfs/python/syncdaemon/repce.py", line 118, in worker     res = getattr(self.obj, rmeth)(*in_data[2:])   File "/usr/libexec/glusterfs/python/syncdaemon/resource.py", line 588, in entry_ops     src_entry = get_slv_dir_path(slv_host, slv_volume, gfid)   File "/usr/libexec/glusterfs/python/syncdaemon/syncdutils.py", line 710, in get_slv_dir_path     dir_entry = os.path.join(pfx, pargfid, basename)   File "/usr/lib64/python2.7/posixpath.py", line 75, in join     if b.startswith('/'): AttributeError: 'int' object has no attribute 'startswith' In pyhthon3: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.8/posixpath.py", line 90, in join genericpath._check_arg_types('join', a, *p) File "/usr/lib64/python3.8/genericpath.py", line 152, in _check_arg_types raise TypeError(f'{funcname}() argument must be str, bytes, or ' TypeError: join() argument must be str, bytes, or os.PathLike object, not 'int' </snip> Backport of: >Ptach link: https://review.gluster.org/#/c/glusterfs/+/24468/ >Change-Id: I8b926899c60ad8c4ffc886d57028ba70fd21e332 >Fixes: #1250 >Signed-off-by: Sunny Kumar <sunkumar@redhat.com> Change-Id: I8b926899c60ad8c4ffc886d57028ba70fd21e332 Fixes: #1250 Signed-off-by: Sunny Kumar <sunkumar@redhat.com> (cherry picked from commit 27f5c8ba844e9da54fc1304df4ffe015a3bbb9bd)
* cluster/ec: Improve detection of new healsXavi Hernandez2020-08-196-28/+84
| | | | | | | | | | | | | | | | | | | | When EC successfully healed a directory it assumed that maybe other entries inside that directory could have been created, which could require additional heal cycles. For this reason, when the heal happened as part of one index heal iteration, it triggered a new iteration. The problem happened when the directory was healthy, so no new entries were added, but its index entry was not removed for some reason. In this case self-heal started and endless loop healing the same directory continuously, cause high CPU utilization. This patch improves detection of new files added to the heal index so that a new index heal iteration is only triggered if there is new work to do. Change-Id: I2355742b85fbfa6de758bccc5d2e1a283c82b53f Fixes: #1354 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* Issue with gf_fill_iatt_for_direntSoumya Koduri2020-08-121-1/+1
| | | | | | | | | | | | | In "gf_fill_iatt_for_dirent()", while calculating inode_path for loc, the inode should be of parent's. Instead it is loc.inode which results in error and eventually lookup/readdirp fails. This patch fixes the same. Change-Id: Ied086234a4634e8cb13520521ac547c87b3c76b5 Fixes: #1351 Signed-off-by: Soumya Koduri <skoduri@redhat.com> (cherry picked from commit ab8308333aaf033e07dbbdf2f69f9313a7e311f3)
* doc: Added release 7.7 notesv7.7Rinku Kothiya2020-07-201-0/+31
| | | | | | | Fixes: #1315 Change-Id: I722f540428058f1ac2f3a476d0c374551d8bc283 Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* features/shard: Convert shard block indices to uint64Krutika Dhananjay2020-07-132-7/+10
| | | | | | | | | | | | | | | This patch fixes a crash in FOPs that operate on really large sharded files where number of participant shards could sometimes exceed signed int32 max. The patch also adds GF_ASSERTs to ensure that number of participating shards is always greater than 0 for files that do have more than one shard. Change-Id: I354de58796f350eb1aa42fcdf8092ca2e69ccbb6 Fixes: #1348 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com> (cherry picked from commit cdf01cc47eb2efb427b5855732d9607eec2abc8a)
* fuse: occasional logging for fuse device 'weird' write errorsCsaba Henk2020-07-132-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change is a followup to I510158843e4b1d482bdc496c2e97b1860dc1ba93. In referred change we pushed log messages about 'weird' write errors to fuse device out of sight, by reporting them at Debug loglevel instead of Error (where 'weird' means errno is not POSIX compliant but having meaningful semantics for FUSE protocol). This solved the issue of spurious error reporting. And so far so good: these messages don't indicate an error condition by themselves. However, when they come in high repetitions, that indicates a suboptimal condition which should be reported.[1] Therefore now we shall emit a Warning if a certain errno occurs a certain number of times[2] as the outcome of a write to the fuse device. ___ [1] typically ENOENTs and ENOTDIRs accumulate when glusterfs' inode invalidation lags behind the kernel's internal inode garbage collection (in this case above errnos mean that the inode which we requested to be invalidated is not found in kernel). This can be mitigated with the invalidate-limit command line / mount option, cf. bz#1732717. [2] 256, as of the current implementation. Change-Id: I8cc7fe104da43a88875f93b0db49d5677cc16045 Updates: #1000 Signed-off-by: Csaba Henk <csaba@redhat.com>
* features/shard: Aggregate file size, block-count before unwinding removexattrKrutika Dhananjay2020-07-133-70/+208
| | | | | | | | | | | | | | Posix translator returns pre and postbufs in the dict in {F}REMOVEXATTR fops. These iatts are further cached at layers like md-cache. Shard translator, in its current state, simply returns these values without updating the aggregated file size and block-count. This patch fixes this problem. Change-Id: I4b2dd41ede472c5829af80a67401ec5a6376d872 Fixes: #1243 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com> (cherry picked from commit 32519525108a2ac6bcc64ad931dc8048d33d64de)
* cluster/afr: Prioritize ENOSPC over other errorskarthik-us2020-06-224-48/+86
| | | | | | | | | | | | | | | | | | | | | | | Problem: In a replicate/arbiter volume if file creations or writes fails on quorum number of bricks and on one brick it is due to ENOSPC and on other brick it fails for a different reason, it may fail with errors other than ENOSPC in some cases. Fix: Prioritize ENOSPC over other lesser priority errors and do not set op_errno in posix_gfid_set if op_ret is 0 to avoid receiving any error_no which can be misinterpreted by __afr_dir_write_finalize(). Also removing the function afr_has_arbiter_fop_cbk_quorum() which might consider a successful reply form a single brick as quorum success in some cases, whereas we always need fop to be successful on quorum number of bricks in arbiter configuration. Change-Id: I106e267f8b9451f681022f1cccb410d9bc824c08 Fixes: #1254 Signed-off-by: karthik-us <ksubrahm@redhat.com> (cherry picked from commit fa63b45ca5edf172b1b89b28b5db3c5129cc57b6)
* afr: more quorum checks in lookup and new entry markingRavishankar N2020-06-184-13/+25
| | | | | | | | | | | | | | | | | Problem: See github issue for details. Fix: -In lookup if the entry exists in 2 out of 3 bricks, don't fail the lookup with ENOENT just because there is an entrylk on the parent. Consider quorum before deciding. -If entry FOP does not succeed on quorum no. of bricks, do not perform new entry mark. Fixes: #1303 Change-Id: I56df8c89ad53b29fa450c7930a7b7ccec9f4a6c5 Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit c4a6748f25d2c1ab3ebcf89952278ebf94c8d371)
* features/shard: Aggregate size, block-count in iatt before unwinding setxattrKrutika Dhananjay2020-06-152-17/+222
| | | | | | | | | | | | | | Posix translator returns pre and postbufs in the dict in {F}SETXATTR fops. These iatts are further cached at layers like md-cache. Shard translator, in its current state, simply returns these values without updating the aggregated file size and block-count. This patch fixes this problem. Change-Id: I4da0eceb4235b91546df79270bcc0af8cd64e9ea Fixes: #1243 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com> (cherry picked from commit 29ec66c6ab77e2d6893c6e213a3d1fb148702c99)
* open-behind: rewrite of internal logicXavi Hernandez2020-06-1512-823/+1393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a critical flaw in the previous implementation of open-behind. When an open is done in the background, it's necessary to take a reference on the fd_t object because once we "fake" the open answer, the fd could be destroyed. However as long as there's a reference, the release function won't be called. So, if the application closes the file descriptor without having actually opened it, there will always remain at least 1 reference, causing a leak. To avoid this problem, the previous implementation didn't take a reference on the fd_t, so there were races where the fd could be destroyed while it was still in use. To fix this, I've implemented a new xlator cbk that gets called from fuse when the application closes a file descriptor. The whole logic of handling background opens have been simplified and it's more efficient now. Only if the fop needs to be delayed until an open completes, a stub is created. Otherwise no memory allocations are needed. Correctly handling the close request while the open is still pending has added a bit of complexity, but overall normal operation is simpler. Change-Id: I6376a5491368e0e1c283cc452849032636261592 Fixes: #1225 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* cluster/ec: Return correct error code and log messageAshish Pandey2020-06-151-2/+9
| | | | | | | | | | | | | In case of readdir was send with an FD on which opendir was failed, this FD will be useless and we return it with error. For now, we are returning it with EINVAL without logging any message in log file. Return a correct error code and also log the message to improve thing to debug. fixes: #1220 Change-Id: Iaf035254b9c5aa52fa43ace72d328be622b06169 (cherry picked from commit af70cb5eedd80207cd184e69f2a4fb252b72d070)
* performance/open-behind: seek fop should open_and_resumePranith Kumar K2020-06-101-0/+27
| | | | | | | | | | | Backport of: > fixes: bz#1760187 > Change-Id: I4c6ad13194d4fc5c7705e35bf9a27fce504b51f9 > Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> Fixes: #1296 Change-Id: I4c6ad13194d4fc5c7705e35bf9a27fce504b51f9 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* tests: skip tests on absence of reflink in xfsPranith Kumar K2020-06-103-10/+12
| | | | | | Fixes: #1223 Change-Id: I36cb72d920ffd77405051546615c5262c392daef Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* doc: Added release 7.6 notesv7.6Rinku Kothiya2020-05-181-0/+27
| | | | | | | Fixes: #1247 Change-Id: Ic9571066aa83fc2142e3583ddf1f1b885e83470c Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* md-cache: fix several NULL dereferencesXavi Hernandez2020-05-091-66/+129
| | | | | | | | | | | | | | This patch includes the following CID from Coverity Scan: * 1425196 * 1425197 * 1425198 * 1425199 * 1525200 Change-Id: Iddcfea449d3dd56d4dfcc39f4c3c608518e611e4 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Updates: #1060
* afr: event gen changesRavishankar N2020-05-094-82/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The general idea of the changes is to prevent resetting event generation to zero in the inode ctx, since event gen is something that should follow 'causal order'. Change #1: For a read txn, in inode refresh cbk, if event_generation is found zero, we are failing the read fop. This is not needed because change in event gen is only a marker for the next inode refresh to happen and should not be taken into account by the current read txn. Change #2: The event gen being zero above can happen if there is a racing lookup, which resets even get (in afr_lookup_done) if there are non zero afr xattrs. The resetting is done only to trigger an inode refresh and a possible client side heal on the next lookup. That can be acheived by setting the need_refresh flag in the inode ctx. So replaced all occurences of resetting even gen to zero with a call to afr_inode_need_refresh_set(). Change #3: In both lookup and discover path, we are doing an inode refresh which is not required since all 3 essentially do the same thing- update the inode ctx with the good/bad copies from the brick replies. Inode refresh also triggers background heals, but I think it is okay to do it when we call refresh during the read and write txns and not in the lookup path. The .ts which relied on inode refresh in lookup path to trigger heals are now changed to do read txn so that inode refresh and the heal happens. Change-Id: Iebf39a9be6ffd7ffd6e4046c96b0fa78ade6c5ec Fixes: #1179 Signed-off-by: Ravishankar N <ravishankar@redhat.com> Reported-by: Erik Jacobson <erik.jacobson at hpe.com> (cherry picked from commit f0fcd909ad4535b60c9208d4804ebe6afe421a09)
* md-cache: avoid clearing cache when not necessaryXavi Hernandez2020-05-091-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>
* gfapi: Suspend synctasks instead of blocking themSoumya Koduri2020-05-093-2/+50
| | | | | | | | | | | | | | | | | | | | | | | | | There are certain conditions which blocks the current execution thread (like waiting on mutex lock or condition variable or I/O response). In such cases, if it is a synctask thread, we should suspend the task instead of blocking it (like done in SYNCOP using synctask_yield) This is to avoid deadlock like the one mentioned below - 1) synctaskA sets fs->migration_in_progress to 1 and does I/O (LOOKUP) 2) Other synctask threads wait for fs->migration_in_progress to be reset to 0 by synctaskA and hence blocked 3) but synctaskA cannot resume as all synctask threads are blocked on (2). Note: this same approach is already used by few other components like syncbarrier etc. Change-Id: If90f870d663bb242c702a5b86ac52eeda67c6f0d Fixes: #1146 Signed-off-by: Soumya Koduri <skoduri@redhat.com> (cherry picked from commit 55914f968d907ed747774da15285b42653afda61)
* fuse: degrade logging of write failure to fuse deviceCsaba Henk2020-05-052-7/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: FUSE uses failures of communicating with /dev/fuse with various errnos to indicate in-kernel conditions to userspace. Some of these shouldn't be handled as an application error. Also the standard POSIX errno description should not be shown as they are misleading in this context. Solution: When writing to the fuse device, the caller of the respective convenience routine can mask those errnos which don't qualify to be an error for the application in that context, so then those shall be reported at DEBUG level. The possible non-standard errnos are reported with their POSIX name instead of their description to avoid confusion. (Eg. for ENOENT we don't log "no such file or directory", we log indeed literal "ENOENT".) Change-Id: I510158843e4b1d482bdc496c2e97b1860dc1ba93 >updates: bz#1193929 updates: #1000 Signed-off-by: Csaba Henk <csaba@redhat.com> (cherry picked from commit 1166df1920dd9b2bd5fce53ab49d27117db40238)
* doc: Added release 7.5 notesv7.5Rinku Kothiya2020-04-161-0/+28
| | | | | | | Fixes: #1174 Change-Id: Idca6d5dd2d069435df9a6882a6bef32fb6916bb9 Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* posix: log aio_error return codes in posix_fs_health_checkMohit Agrawal2020-04-141-3/+2
| | | | | | | | | | | | | | | | | | Problem: Sometime brick is going down to health check thread is failed without logging error codes return by aio system calls. As per aio_error man page it returns a positive error number if the asynchronous I/O operation failed. Solution: log aio_error return codes in error message > Change-Id: I2496b1bc16e602b0fd3ad53e211de11ec8c641ef > (Cherry picked from commit 032862fa3944fc7152140aaa13cdc474ae594a51) > (Reviwed on upstream link https://review.gluster.org/#/c/glusterfs/+/23284/ > Signed-off-by: Mohit Agrawal <moagrawal@redhat.com> Change-Id: I2496b1bc16e602b0fd3ad53e211de11ec8c641ef Fixes: #1168 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* mount/fuse: Wait for 'mount' child to exit before dyingPranith Kumar K2020-04-141-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>
* snap_scheduler: python3 compatibility and new test caseSunny Kumar2020-04-142-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: "snap_scheduler.py init" command failing with the below traceback: [root@dhcp43-104 ~]# snap_scheduler.py init Traceback (most recent call last): File "/usr/sbin/snap_scheduler.py", line 941, in <module> sys.exit(main(sys.argv[1:])) File "/usr/sbin/snap_scheduler.py", line 851, in main initLogger() File "/usr/sbin/snap_scheduler.py", line 153, in initLogger logfile = os.path.join(process.stdout.read()[:-1], SCRIPT_NAME + ".log") File "/usr/lib64/python3.6/posixpath.py", line 94, in join genericpath._check_arg_types('join', a, *p) File "/usr/lib64/python3.6/genericpath.py", line 151, in _check_arg_types raise TypeError("Can't mix strings and bytes in path components") from None TypeError: Can't mix strings and bytes in path components Solution: Added the 'universal_newlines' flag to Popen to support backward compatibility. Added a basic test for snapshot scheduler. Backport of: >Upstream patch: >https://review.gluster.org/#/c/glusterfs/+/24257/ >Change-Id: I78e8fabd866fd96638747ecd21d292f5ca074a4e >Fixes: #1134 >Signed-off-by: Sunny Kumar <sunkumar@redhat.com> >(cherry picked from commit a7d7ec066e56ac03bf252c26beb20fdc2c3b6772) Change-Id: I78e8fabd866fd96638747ecd21d292f5ca074a4e Fixes: #1134 Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
* features/utime: Don't access frame after stack-windPranith Kumar K2020-04-072-15/+52
| | | | | | | | | | | | | 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. Fixes: #832 Change-Id: I64754609f1114b0bbd4d1336fa81a56f2cca6e03 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* write-behind: fix data corruptionXavi Hernandez2020-04-073-2/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* utime: resolve an issue of permission denied logsAmar Tumballi2020-04-072-1/+12
| | | | | | | | | | | | | 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 Updates: #832 Signed-off-by: Amar Tumballi <amar@kadalu.io> (cherry picked from commit eb916c057036db8289b41265797e5dce066d1512)
* features/shard: Fix crash during shards cleanup in error casesKrutika Dhananjay2020-04-071-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> (cherry picked from commit cc43ac8651de9aa508b01cb259b43c02d89b2afc)
* afr: mark pending xattrs as a part of metadata healRavishankar N2020-04-072-1/+120
| | | | | | | | | | | | | | | | | | | | ...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. Updates: #1067 Change-Id: If1b050b70b0ad911e162c04db4d89b263e2b8d7b Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit 2d5ba449e9200b16184b1e7fc84cabd015f1f779)
* open-behind: fix missing fd referenceXavi Hernandez2020-04-071-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 an entry fop (unlink, rename, ...) caused destruction of the fd while it was still being used. Change-Id: Ie9e992902cf2cd7be4af1f8b4e57af9bd6afd8e9 Fixes: #1028 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* doc: Added release 7.4 notesv7.4Rinku Kothiya2020-03-181-0/+31
| | | | | | | Fixes: #1124 Change-Id: I02fbb97ea7ab7617086ebcece07213e67cb1aa67 Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* cluster/ec: Change handling of heal failure to avoid crashAshish Pandey2020-03-172-13/+13
| | | | | | | | | | | | | | | | | Problem: ec_getxattr_heal_cbk was called with NULL as second argument in case heal was failing. This function was dereferencing "cookie" argument which caused crash. Solution: Cookie is changed to carry the value that was supposed to be stored in fop->data, so even in the case when fop is NULL in error case, there won't be any NULL dereference. Thanks to Xavi for the suggestion about the fix. Change-Id: I0798000d5cadb17c3c2fbfa1baf77033ffc2bb8c updates: #1061
* glusterd: Brick process fails to come up with brickmux onVishal Pandey2020-03-172-7/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 > Bug: bz#1773856 > Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com> (cherry picked from commit 45e81aae791da9d013aba2286af44826227c05ec) Change-Id: Idfe0e8710f7eb77ca3ddfa1cabeb45b2987f41aa fixes: bz#1808964 Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
* events: fix IPv6 memory corruptionXavi Hernandez2020-03-171-41/+15
| | | | | | | | | | | | | | | | | | When an event was generated and the target host was resolved to an IPv6 address, there was a memory overflow when that address was copied to a fixed IPv4 structure (IPv6 addresses are longer than IPv4 ones). This fix correctly handles IPv4 and IPv6 addresses returned by getaddrinfo() Backport of: > Change-Id: I5864a0c6e6f1b405bd85988529570140cf23b250 > Fixes: bz#1790870 > Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Change-Id: I5864a0c6e6f1b405bd85988529570140cf23b250 Fixes: #1030 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* glusterd: stop stale bricks during handshaking in brick mux modeAtin Mukherjee2020-03-164-9/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses two problems: 1. During friend handshaking, if a volume is imported due to change in the version, the old bricks were not stopped which would lead to a situation where bricks will run with old volfiles. 2. As part of attaching shd service in glusterd_attach_svc, there might be a case that the volume for which we're attempting to attach a shd service might become stale and in the process of deletion and hence in every retrials (if the rpc connection isn't ready) check for the existance of the volume and then only attempt the further attach request. patch on master: https://review.gluster.org/#/c/glusterfs/+/23042/ > Bug: bz#1733425 > Change-Id: I6bac6b871f7e31cb5bf277db979289dec196a03e > Signed-off-by: Atin Mukherjee <amukherj@redhat.com> > Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com> fixes: bz#1812849 Change-Id: I6bac6b871f7e31cb5bf277db979289dec196a03e Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
* multiple: fix bad type castXavi Hernandez2020-03-166-21/+42
| | | | | | | | | | | | | | | | | When using inode_ctx_get() or inode_ctx_set(), a 'uint64_t *' is expected. In many cases, the value to retrieve or store is a pointer, which will be of smaller size in some architectures (for example 32-bits). In this case, directly passing the address of the pointer casted to an 'uint64_t *' is wrong and can cause memory corruption. Backport of: > Change-Id: Iae616da9dda528df6743fa2f65ae5cff5ad23258 > Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> > Fixes: bz#1785611 Change-Id: Iae616da9dda528df6743fa2f65ae5cff5ad23258 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: bz#1785323
* cluster/afr: fix race when bricks come upXavi Hernandez2020-03-163-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. Backport of: > Change-Id: I7ed6108554ca379d532efb1a29b2de8085410b70 > Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> > Fixes: bz#1808875 Change-Id: I7ed6108554ca379d532efb1a29b2de8085410b70 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: bz#1809438
generated by cgit (git 2.34.1) at 2024-04-23 12:08:26 +0000