summaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* afr: prevent winding inodelks twice for arbiter volumesRavishankar N2018-10-121-0/+44
| | | | | | | | | | | | | | | | | | | | | Backport of https://review.gluster.org/#/c/glusterfs/+/21380/ Problem: In an arbiter volume, if there is a pending data heal of a file only on arbiter brick, self-heal takes inodelks twice due to a code-bug but unlocks it only once, leaving behind a stale lock on the brick. This causes the next write to the file to hang. Fix: Fix the code-bug to take lock only once. This bug was introduced master with commit eb472d82a083883335bc494b87ea175ac43471ff Thanks to Pranith Kumar K <pkarampu@redhat.com> for finding the RCA. fixes: bz#1637989 Change-Id: I15ad969e10a6a3c4bd255e2948b6be6dcddc61e1 BUG: 1637989 Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* cluster/afr: Delegate metadata heal with pending xattrs to SHDPranith Kumar K2018-10-122-13/+25
| | | | | | | | | | | | | | | | | | | Problem: When metadata-self-heal is triggered on the mount, it blocks lookup until metadata-self-heal completes. But that can lead to hangs when lot of clients are accessing a directory which needs metadata heal and all of them trigger heals waiting for other clients to complete heal. Fix: Only when the heal is needed but the pending xattrs are not set, trigger metadata heal that could block lookup. This is the only case where different clients may give different metadata to the clients without heals, which should be avoided. Updates bz#1625588 Change-Id: I6089e9fda0770a83fb287941b229c882711f4e66 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/afr: Delegate name-heal when possiblePranith Kumar K2018-10-122-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | Problem: When name-self-heal is triggered on the mount, it blocks lookup until name-self-heal completes. But that can lead to hangs when lot of clients are accessing a directory which needs name heal and all of them trigger heals waiting for other clients to complete heal. Fix: When a name-heal is needed but quorum number of names have the file and pending xattrs exist on the parent, then better to delegate the heal to SHD which will be completed as part of entry-heal of the parent directory. We could also do the same for quorum-number of names not present but we don't have any known use-case where this is a frequent occurrence so not changing that part at the moment. When there is a gfid mismatch or missing gfid it is important to complete the heal so that next rename doesn't assume everything is fine and perform a rename etc fixes bz#1625588 Change-Id: I8b002c85dffc6eb6f2833e742684a233daefeb2c Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* dht: Fill first_up_subvol before use in dht_opendirPoornima G2018-10-101-0/+23
| | | | | | | | Reported by: Sam McLeod Change-Id: Ic8f9b46b173796afd70aff1042834b03ac3e80b2 BUG: 1512371 Signed-off-by: Poornima G <pgurusid@redhat.com>
* afr: fix incorrect reporting of directory split-brainRavishankar N2018-10-102-1/+63
| | | | | | | | | | | | | | | | | | | | Backport of https://review.gluster.org/#/c/glusterfs/+/21135/ Problem: When a directory has dirty xattrs due to failed post-ops or when replace/reset brick is performed, AFR does a conservative merge as expected, but heal-info reports it as split-brain because there are no clear sources. Fix: Modify pending flag to contain information about pending heals and split-brains. For directories, if spit-brain flag is not set,just show them as needing heal and not being in split-brain. Fixes: bz#1633625 Change-Id: I09ef821f6887c87d315ae99e6b1de05103cd9383 BUG: 1633625 Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* glusterd: volume inode/fd status broken with brick muxhari gowtham2018-09-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | backport of:https://review.gluster.org/#/c/19846/6 Problem: The values for inode/fd was populated from the ctx received from the server xlator. Without brickmux, every brick from a volume belonged to a single brick from the volume. So searching the server and populating it worked. With brickmux, a number of bricks can be confined to a single process. These bricks can be from different volumes too (if we use the max-bricks-per-process option). If they are from different volumes, using the server xlator to populate causes problem. Fix: Use the brick to validate and populate the inode/fd status. >Signed-off-by: hari gowtham <hgowtham@redhat.com> >Change-Id: I2543fa5397ea095f8338b518460037bba3dfdbfd >fixes: bz#1566067 Change-Id: I2543fa5397ea095f8338b518460037bba3dfdbfd BUG: 1569336 fixes: bz#1569336 Signed-off-by: hari gowtham <hgowtham@redhat.com>
* io-stats: dump io-stats info in /var/run/glusterAmar Tumballi2018-09-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | It wouldn't make sense to allow iostats file to be written in *any* directory. While the formating makes sure we try to append io-stats-name for the file, so overwriting existing file is slim, but in any case it makes sense to restrict dumping to one directory. Below are the sample commands, and files created for the corresponding values: $ setfattr -n trusted.io-stats-dump -v file-for-dump $M0 In this case, the file would be in /var/run/gluster/file-for-dump $ setfattr -n trusted.io-stats-dump -v /dir1/dir2/file-for-dump $M0 In this case, then the dump file is in /var/run/gluster/dir1-dir2-file-for-dump Note that the value passed for this virtual xattr would be treated as a file, and even if the value has '/' in it, it would be changed to '-' for sanity. BUG: 1625660 Change-Id: Id9ae6a40a190b8937c51662e6e1c2a0f6c86a0e0 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* afr: heal gfids when file is not present on all bricksRavishankar N2018-07-111-0/+125
| | | | | | | | | | | | | | | Backport of https://review.gluster.org/#/c/20271/ (only change is in .t) commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265 introduced a regression wherein if a file is present in only 1 brick of replica *and* doesn't have a gfid associated with it, it doesn't get healed upon the next lookup from the client. Fix it. Change-Id: I7d1111dcb45b1b8b8340a7d02558f05df70aa599 BUG: 1598121 fixes: bz#1598121 Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit eb472d82a083883335bc494b87ea175ac43471ff)
* afr: fix bug-1363721.t failureRavishankar N2018-07-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | Backport of https://review.gluster.org/#/c/20036/ Note: We need to update inode context's write_subvol even in case of compound fops. This is not there in master and 4.1 since compound FOPS was removed in it. Problem: In the .t, when the only good brick was brought down, writes on the fd were still succeeding on the bad bricks. The inflight split-brain check was marking the write as failure but since the write succeeded on all the bad bricks, afr_txn_nothing_failed() was set to true and we were unwinding writev with success to DHT and then catching the failure in post-op in the background. Fix: Don't wind the FOP phase if the write_subvol (which is populated with readable subvols obtained in pre-op cbk) does not have at least 1 good brick which was up when the transaction started. Change-Id: I4a1fef4569609c31cffeaef591a64c10870e8d0b BUG: 1598720 Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* afr: add quorum checks in post-opRavishankar N2018-07-041-1/+1
| | | | | | | | | | | afr relies on pending changelog xattrs to identify source and sinks and the setting of these xattrs happen in post-op. So if post-op fails, we need to unwind the write txn with a failure. Change-Id: I0f019ac03890108324ee7672883d774918b20be1 BUG: 1597120 Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit a40a87ec3b226ae86a6ed8f4af25b45965a20cad)
* afr: don't treat all cases all bricks being blamed as split-brainRavishankar N2018-07-043-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | Problem: We currently don't have a roll-back/undoing of post-ops if quorum is not met. Though the FOP is still unwound with failure, the xattrs remain on the disk. Due to these partial post-ops and partial heals (healing only when 2 bricks are up), we can end up in split-brain purely from the afr xattrs point of view i.e each brick is blamed by atleast one of the others. These scenarios are hit when there is frequent connect/disconnect of the client/shd to the bricks while I/O or heal are in progress. Fix: Instead of undoing the post-op, pick a source based on the xattr values. If 2 bricks blame one, the blamed one must be treated as sink. If there is no majority, all are sources. Once we pick a source, self-heal will then do the heal instead of erroring out due to split-brain. Change-Id: I3d0224b883eb0945785ade0e9697a1c828aec0ae BUG: 1597123 Signed-off-by: Ravishankar N <ravishankar@redhat.com> (cherry picked from commit 0e6e8216823c2d9dafb81aae0f6ee3497c23d140)
* storage/posix: Fix posix_symlinks_match()Pranith Kumar K2018-07-041-5/+10
| | | | | | | | | | | 1) snprintf into linkname_expected should happen with PATH_MAX 2) comparison should happen with linkname_actual with complete string linkname_expected fixes bz#1595528 Change-Id: Ic3b3c362dc6c69c046b9a13e031989be47ecff14 BUG: 1595528 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* storage/posix: Handle ENOSPC correctly in zero_fillPranith Kumar K2018-06-252-0/+99
| | | | | | | Change-Id: Icc521d86cc510f88b67d334b346095713899087a BUG: 1591187 fixes: bz#1591187 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* use awk to get a specific line from the output instead of cutRaghavendra Bhat2018-06-111-7/+1
| | | | | | | | | | | cut -d$'\n' is not separating the xattrs shown as part of getfattr output. Hence use awk to get the nth line of getfattr output for nth iteration in the for loop. Change-Id: I1a96cd3f72f4f407f9a783375f78d9a69d5d3885 fixes: bz#1580519 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com> (cherry picked from commit bef654f48c14bfd7ce20702edff41052f6f54bdc)
* test: Marking test case bug-1309462.t as badShyamsundarR2018-05-231-1/+2
| | | | | | | | | | Details in the bug Updates: bz#1581746 Change-Id: Id984e10b60daf274d5510e3ccbf7abf0cb19f368 Signed-off-by: ShyamsundarR <srangana@redhat.com> (cherry picked from commit 92839c5a4a6c87973e4f6f2f96b359e9c2a0f5c0)
* features/index: Choose different base file on EMLINK errorPranith Kumar K2018-04-121-0/+52
| | | | | | | Change-Id: I4648816af908539efdc2528608aa2ebf7f0d0e2f fixes: bz#1565655 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> (cherry picked from commit bb12f2109a01856e8184e13cf984210d20155b13)
* cluster/ec: send list-node-uuids request to all subvolumesXavi Hernandez2018-04-061-0/+1
| | | | | | | | | | | | | | | The xattr trusted.glusterfs.list-node-uuids was only sent to a single subvolume. This was returning null uuids from the other subvolumes as if they were down. This fix forces that xattr to be requested from all subvolumes. Backport of: > BUG: 1561406 Change-Id: If62eb39a6857258923ba625e153d4ad79018ea2f BUG: 1561731 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* cluster/ec: Change default read policy to gfid-hashAshish Pandey2018-04-061-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Whenever we read data from file over NFS, NFS reads more data then requested and caches it. Based on the stat information it makes sure that the cached/pre-read data is valid or not. Consider 4 + 2 EC volume and all the bricks are on differnt nodes. In EC, with round-robin read policy, reads are sent on different set of data bricks. This way, it balances the read fops to go on all the bricks and avoid heating UP (overloading) same set of bricks. Due to small difference in clock speed, it is possible that we get minor difference for atime, mtime or ctime for different bricks. That might cause a different stat returned to NFS based on which NFS will discard cached/pre-read data which is actually not changed and could be used. Solution: Change read policy for EC as gfid-hash. That will force all the read to go to same set of bricks. >Change-Id: I825441cc519e94bf3dc3aa0bd4cb7c6ae6392c84 >BUG: 1554743 >Signed-off-by: Ashish Pandey <aspandey@redhat.com> Change-Id: I825441cc519e94bf3dc3aa0bd4cb7c6ae6392c84 BUG: 1558352 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: avoid delays in self-healXavi Hernandez2018-04-061-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Self-heal creates a thread per brick to sweep the index looking for files that need to be healed. These threads are started before the volume comes online, so nothing is done but waiting for the next sweep. This happens once per minute. When a replace brick command is executed, the new graph is loaded and all index sweeper threads started. When all bricks have reported, a getxattr request is sent to the root directory of the volume. This causes a heal on it (because the new brick doesn't have good data), and marks its contents as pending to be healed. This is done by the index sweeper thread on the next round, one minute later. This patch solves this problem by waking all index sweeper threads after a successful check on the root directory. Additionally, the index sweep thread scans the index directory sequentially, but it might happen that after healing a directory entry more index entries are created but skipped by the current directory scan. This causes the remaining entries to be processed on the next round, one minute later. The same can happen in the next round, so the heal is running in bursts and taking a lot to finish, specially on volumes with many directory levels. This patch solves this problem by immediately restarting the index sweep if a directory has been healed. Backport of: > BUG: 1547662 Change-Id: I58d9ab6ef17b30f704dc322e1d3d53b904e5f30e BUG: 1555201 Signed-off-by: Xavi Hernandez <jahernan@redhat.com>
* cluster/afr: Fail open on split-brainPranith Kumar K2018-03-081-0/+38
| | | | | | | | | | | | | | | | | | Problem: Append on a file with split-brain succeeds. Open is intercepted by open-behind, when write comes on the file, open-behind does open+write. Open succeeds because afr doesn't fail it. Then write succeeds because write-behind intercepts it. Flush is also intercepted by write-behind, so the application never gets to know that the write failed. Fix: Fail open on split-brain, so that when open-behind does open+write open fails which leads to write failure. Application will know about this failure. Change-Id: I4bff1c747c97bb2925d6987f4ced5f1ce75dbc15 BUG: 1544635 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> (cherry picked from commit 786343abca3474ff01aa1017210112d97cbc4843)
* tests/dht: Non-root can delete stale linkto filesN Balachandran2018-02-121-0/+51
| | | | | | | | | | | | | Test to check that non-root users can delete stale linkto files > Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4 > BUG: 1542318 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: Ic9bc76bc485cab839927af60cfce78a058eee2e4 BUG: 1543016 Signed-off-by: N Balachandran <nbalacha@redhat.com>
* nfs: Fixing the failure in bug-974972.t test casekarthik-us2018-02-121-0/+1
| | | | | | | | | | | | | | | | Problem: gNFS servers is restarted even before the pending marker is set becuase of eager lock being on, leading to a file in split-brain to get healed. Fix: Switch off the eager lock. This is fixed in the later versions by the patch: https://review.gluster.org/#/c/13075/ Change-Id: If59e5ede2de1cbfcdeac01cca38dc0d046f1993c BUG: 1542475 Signed-off-by: karthik-us <ksubrahm@redhat.com>
* tests: mark test badN Balachandran2018-02-071-0/+6
| | | | | | | | Please remove after fixing the test. Change-Id: If6c36dc6c395730dfb17b5b4df6f24629d904926 BUG: 1542826 Signed-off-by: N Balachandran <nbalacha@redhat.com>
* tests: Spurious failure multiplex-limit-issue-151.tN Balachandran2018-02-061-1/+1
| | | | | | | | | | | | | A timing issue caused the remove-brick commit to fail. Replaced 'remove-brick commit' with 'remove-brick force'. > Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4 > BUG: 1517904 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: I69144b2f7be34095dbd3a7d182e0bf01b27fb0a4 BUG: 1542615 Signed-off-by: N Balachandran <nbalacha@redhat.com>
* tests: Fix a broken test casePoornima G2018-02-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | Issue: When using statedump command to take statedump of the gfapi process, we specify the following things: $gluster volume statedump <volname> client <host>:<pid> pid: Pid of the gfapi application host: This should be the IP/hostname as seen by the glusterd, the gfapi application is connected to. In this test case, if gfapi application is running locally, and is connected to $H1 glusterd, the <host> need not be $H1. <host> could be localhost, 127.0.0.1, 127.1.1.1 etc. based on the configuration of the system. Hence use netstat to find the right <host> value. >mainline patch : https://review.gluster.org/#/c/18893/ Change-Id: I6efb9d1ccaf9c6841a9ab7c9ebfecafc03c0bc5e BUG: 1542054 Signed-off-by: Poornima G <pgurusid@redhat.com>
* cluster/ec: OpenFD heal implementation for ECSunil Kumar Acharya2018-02-024-11/+129
| | | | | | | | | | | | | | | | Existing EC code doesn't try to heal the OpenFD to avoid unnecessary healing of the data later. Fix implements the healing of open FDs before carrying out file operations on them by making an attempt to open the FDs on required up nodes. Backport of: >BUG: 1431955 BUG: 1536334 Change-Id: Ib696f59c41ffd8d5678a484b23a00bb02764ed15 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* posix: delete stale gfid handles in nameless lookupRavishankar N2018-01-161-0/+65
| | | | | | | | | | | ..in order for self-heal of symlinks to work properly (see BZ for details). Backport of https://review.gluster.org/#/c/19070/ Signed-off-by: Ravishankar N <ravishankar@redhat.com> Change-Id: I9a011d00b07a690446f7fd3589e96f840e8b7501 BUG: 1534847
* cluster/dht: Use percentages for space checkN Balachandran2018-01-121-0/+5
| | | | | | | | | | | | | | | | | | | | | With heterogenous bricks now being supported in DHT we could run into issues where files are not migrated even though there is sufficient space in newly added bricks which just happen to be considerably smaller than older bricks. Using percentages instead of absolute available space for space checks can mitigate that to some extent. Marking bug-1247563.t as that used to depend on the easier code to prevent a file from migrating. This will be removed once we find a way to force a file migration failure. > Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647 > BUG: 1529440 > Signed-off-by: N Balachandran <nbalacha@redhat.com> Change-Id: I3452520511f304dbf5af86f0632f654a92fcb647 BUG: 1530455 Signed-off-by: N Balachandran <nbalacha@redhat.com>
* mount/fuse: use fstat in getattr implementation if any opened fd is availableRaghavendra G2018-01-021-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The restriction of using fds opened by the same Pid means fds cannot be shared across threads of multithreaded application. Note that fops from kernel have different Pid for different threads. Imagine following sequence of operations: * Turn off performance.open-behind * Thread t1 opens an fd - fd1 - on file "file". Let's assume nodeid of "file" is "nodeid-file". * Thread t2 does RENAME ("newfile", "file"). Let's assume nodeid of "newfile" as "nodeid-newfile". * t2 proceeds to do fstat (fd1) The above set of operations can sometimes result in ESTALE/ENOENT errors. RENAME overwrites "file" with "newfile" changing its nodeid from "nodeid-file" to "nodeid-newfile" and post RENAME, "nodeid-file" is removed from the backend. If fstat carries nodeid-file as argument, which can happen if lookup has not refreshed the nodeid of "file" and since t2 doesn't have an fd opened, fuse_getattr_resume uses STAT which will fail as "nodeid-file" no longer exists. Since the above set of operations and sharing of fds across multiple threads are valid, this is a bug. The fix is to use any fd opened on the inode. In this specific example fuse_getattr_resume will find fd1 and winds down the call as fstat (fd1) which won't fail. Cross-checked with "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for any security issues with this solution and he approves the solution. Thanks to "Miklos Szeredi" <mszeredi.at.redhat.dot.com> for all the pointers and discussions. >Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c >BUG: 1510401 >Signed-off-by: Raghavendra G <rgowdapp@redhat.com> (cherry picked from commit 8b57378e5596f287a7b9d106dd6fb56a624b42ee) Change-Id: I88dd29b3607cd2594eee9d72a1637b5346c8d49c BUG: 1529085 Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
* tests: fix bug-1483058-replace-brick-quorum-validation.t spurious failureAtin Mukherjee2017-11-303-1/+19
| | | | | | | | | > mainline patch : https://review.gluster.org/#/c/18710/ Change-Id: I04c35305bfb663eabbf715eee78695adfd4a2d20 BUG: 1512432 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> (cherry picked from commit 76a83f98b78a0bdf29bbb0f8e4c9ab74dae52be4)
* md-cache: avoid checking the xattr value buffer with string functions.Günther Deschner2017-11-091-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | xattrs may very well contain binary, non-text data with leading 0 values. Using strcmp for checking empty values is not the appropriate thing to do: In the best case, it might treat a binary xattr value starting with 0 from being cached (and hence also from being reported back with xattr). In the worst case, we might read beyond the end of a data blob that does contain any zero byte. We fix this by checking the length of the data blob and checking the first byte against 0 if the length is one. > Signed-off-by: Guenther Deschner <gd@samba.org> > Pair-Programmed-With: Michael Adam <obnox@samba.org> > Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11 > BUG: 1476324 > Reviewed-on: https://review.gluster.org/17910 > Reviewed-by: Michael Adam <obnox@samba.org> > Smoke: Gluster Build System <jenkins@build.gluster.org> > Reviewed-by: Poornima G <pgurusid@redhat.com> > Tested-by: Poornima G <pgurusid@redhat.com> > CentOS-regression: Gluster Build System <jenkins@build.gluster.org> > (cherry picked from commit ab4ffdac9dec1867f2d9b33242179cf2b347319d) Change-Id: If723c465a630b8a37b6be58782a2724df7ac6b11 BUG: 1499892 Signed-off-by: Günther Deschner <gd@samba.org>
* protocol/client: handle the subdir handshake properly for add-brickAmar Tumballi2017-11-061-5/+26
| | | | | | | | | | There should be different way we handle handshake in case of subdir mount for the first time, and in case of subsequent graph changes. Change-Id: I2a7ba836433bb0a0f4a861809e2bb0d7fbc4da54 BUG: 1505323 Signed-off-by: Amar Tumballi <amarts@redhat.com> (cherry picked from commit 9aa574a51b84717c1f3949ed2e28a49e49840a93)
* glusterd: delete source brick only once in reset-brick commit forceAtin Mukherjee2017-11-021-0/+24
| | | | | | | | | | | | | | While stopping the brick which is to be reset and replaced delete_brick flag was passed as true which resulted glusterd to free up to source brick before the actual operation. This results commit force to fail failing to find the source brickinfo. > mainline patch : https://review.gluster.org/#/c/18581/ Change-Id: I1aa7508eff7cc9c9b5d6f5163f3bb92736d6df44 BUG: 1507877 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> (cherry picked from commit 0fb8acaa6ff80c43e46deac0ce66b29ae0df0ca4)
* features/worm: Adding check to newloc when doing renameluneo72017-10-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Problem: Since rename didn't check if newloc exists and it's retention state it was possible to rename a new file that wasn't in retention over a existing file that was in read-only state. Cherry picked from commit 00a4dc0: > Change-Id: I63c6bbabb7bb456ebedf201cc77b878ffda62229 > BUG: 1484490 > Signed-off-by: luneo7 <luneo7@gmail.com> > Reviewed-on: https://review.gluster.org/18104 > Tested-by: jiffin tony Thottan <jthottan@redhat.com> > Tested-by: Prashanth Pai <ppai@redhat.com> > Smoke: Gluster Build System <jenkins@build.gluster.org> > CentOS-regression: Gluster Build System <jenkins@build.gluster.org> > Reviewed-by: Prashanth Pai <ppai@redhat.com> > Reviewed-by: Karthik U S <ksubrahm@redhat.com> > Reviewed-by: Amar Tumballi <amarts@redhat.com> Change-Id: I63c6bbabb7bb456ebedf201cc77b878ffda62229 BUG: 1484489 Signed-off-by: luneo7 <luneo7@gmail.com>
* build: make it possible to build cleanly 2x in a rowNiels de Vos2017-10-252-0/+0
| | | | | | | | | | | | | | | | | | | | | | | 'make clean' does not cleanup everything, and some of the files get cleaned too eagerly. Several files are being packaged in a 'make dist' tarball, that get rebuild each time anyway. Specifically, this change prevents - libglusterfs/src/generator.pyc from laying around - keeping rpc/xdr/gen/*.x symlinks - modifying tests/basic/{fuse,gfapi}/Makefile each run - including tests/env.rc and events/src/eventtypes.py in the tarball Cherry picked from commit a413c6353dbfff5221ea020ff8e1475d5ee17a81: > Change-Id: I774dd1abf3a9d3b6a89b938cf6ee7d7792c59a82 > BUG: 1501317 > Reported-by: Patrick Matthäi <pmatthaei@debian.org> > Signed-off-by: Niels de Vos <ndevos@redhat.com> Change-Id: I774dd1abf3a9d3b6a89b938cf6ee7d7792c59a82 BUG: 1494527 Reported-by: Patrick Matthäi <pmatthaei@debian.org> Signed-off-by: Niels de Vos <ndevos@redhat.com>
* protocol-auth: use the proper validation methodAmar Tumballi2017-10-251-0/+4
| | | | | | | | | | Currently, server protocol's init and glusterd's option validation methods are different, causing an issue. They should be same for having consistent behavior Change-Id: Ibbf9a18c7192b2d77f9b7675ae7da9b8d2fe5de4 BUG: 1501315 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* gfapi: set lkowner in glfdSoumya Koduri2017-10-252-0/+239
| | | | | | | | | | | | | | | | | | We need a provision to be able to set lkowner (which is used to distinguish locks maintained by server) in gfapi. Since the same lk_owner need to be used to be able to flush the lock while closing the fd, store the lkowner in the glfd structure itself. A new API has been added to be able to set lkowner in glfd. This is backport of below mainline fix - https://review.gluster.org/#/c/18429 https://review.gluster.org/#/c/18522/ Change-Id: I67591d6b9a89c20b9617d52616513ff9e6c06b47 BUG: 1501956 Signed-off-by: Soumya Koduri <skoduri@redhat.com>
* glusterd:Marking all the brick status as stopped when a process goes down in ↵Sanju Rakonde2017-10-121-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | brick multiplexing In brick multiplexing environment, if a brick process goes down i.e., if we kill it with SIGKILL, the status of the brick for which the process came up for the first time is only changing to stopped. all other brick statuses are remain started. This is happening because the process was killed abruptly using SIGKILL signal and signal handler wasn't invoked and further cleanup wasn't triggered. When we try to start a volume using force, it shows error saying "Request timed out", since all the brickinfo->status are still in started state, we're waiting for one of the brick process to come up which never going to happen since the brick process was killed. To resolve this, In the disconnect event, We are checking all the processes that whether the brick which got disconnected belongs the process. Once we get the process we are calling a function named glusterd_mark_bricks_stopped_by_proc() and sending brick_proc_t object as an argument. From the glusterd_brick_proc_t we can get all the bricks attached to that process. but these are duplicated ones. To get the original brickinfo we are reading volinfo from brick. In volinfo we will have original brickinfo copies. We are changing brickinfo->status to stopped for all the bricks. >Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7 >BUG: 1499509 >Signed-off-by: Sanju Rakonde <srakonde@redhat.com> >Reviewed-on: https://review.gluster.org/#/c/18444/ >Smoke: Gluster Build System <jenkins@build.gluster.org> >CentOS-regression: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: Atin Mukherjee <amukherj@redhat.com> >cherry picked from commit 9422446d72bc054962d72ace9912ecb885946d49) Change-Id: Ifb9054b3ee081ef56b39b2903ae686984fe827e7 BUG: 1501154 Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
* cluster/afr: Make choose-local "reconfigurable"Krutika Dhananjay2017-10-121-0/+18
| | | | | | | | | | | | | | | | Backport of: > Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500 > Reviewed-on: https://review.gluster.org/18026 > BUG: 1480525 > cherry-picked from commit 1e2d6537875d16b783e3c50ada7ee61487c6d796 With this change, enabling choose-local (which means its state makes transition from "off" to "on") will be effective after the first gfid-lookup on "/" since volume-set was executed. Change-Id: Ibab292ba705d993b475cd0303fb3318211fb2500 BUG: 1501022 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* glusterd: disallow replace brick for dist only volumesAtin Mukherjee2017-10-125-62/+17
| | | | | | | | | | | | | | | | | | | | Allowing replace-brick on dist only volumes will lead to data loss. This patch blocks replace brick commit force to fail if a volume is dist only. Also removing tests/basic/pump.t as its of no use as per the discussion in http://lists.gluster.org/pipermail/gluster-devel/2017-September/053652.html >Reviewed-on: https://review.gluster.org/18226 >Smoke: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: N Balachandran <nbalacha@redhat.com> >CentOS-regression: Gluster Build System <jenkins@build.gluster.org> >(cherry picked from commit 7f70d38b66ce755f848ff0197814457a28b321df) Change-Id: Iabb0c16f865f3fc361b64a19bfcf0c0fbb5c2682 BUG: 1493975 Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
* afr: heal gfid as a part of entry healRavishankar N2017-10-101-0/+68
| | | | | | | | | | | | | | | | | | | Problem: If a brick crashes after an entry (file or dir) is created but before gfid is assigned, the good bricks will have pending entry heal xattrs but the heal won't complete because afr_selfheal_recreate_entry() tries to create the entry again and it fails with EEXIST. Fix: We could have fixed posx_mknod/mkdir etc to assign the gfid if the file already exists but the right thing to do seems to be to trigger a lookup on the bad brick and let it heal the gfid instead of winding an mknod/mkdir in the first place. (cherry picked from commit 20fa80057eb430fd72b4fa31b9b65598b8ec1265) Change-Id: I82f76665a7541f1893ef8d847b78af6466aff1ff BUG: 1499202 Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* glusterd: fix client io-threads option for replicate volumesRavishankar N2017-10-091-0/+48
| | | | | | | | | | | | | | | | | | | | | Backport of https://review.gluster.org/#/c/18430/ Problem: Commit ff075a3d6f9b142911d25c27fd209838782bfff0 disabled loading client-io-threads for replicate volumes (it was set to on by default in commit e068c1997314046658dd502e9118dab32decf879) due to performance issues but in doing so, inadvertently failed to load the xlator even if the user explicitly enabled the option using the volume set command. This was despite returning returning sucess for the volume set. Fix: Modify the check in perfxl_option_handler() and add checks in volume create/add-brick/remove-brick code paths, tying it all to GD_OP_VERSION_3_12_2. Change-Id: Ib612973a999a7da818cc926f5c2601b1f0794fcf BUG: 1499158 Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* afr: auto-resolve split-brains for zero-byte filesRavishankar N2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Problems: As described in BZ 1491670, renaming hardlinks can result in data/mdata split-brain of the DHT link-to files (T files) without any mismatch of data and metadata. As described in BZ 1486063, for a zero-byte file with only dirty bits set, arbiter brick will likely be chosen as the source brick. Fix: For zero byte files in split-brain, pick first brick as a) data source if file size is zero on all bricks. b) metadata source if metadata is the same on all bricks In arbiter case, if file size is zero on all bricks and there are no pending afr xattrs, pick 1st brick as data source. (cherry picked from commit 1719cffa911c5287715abfdb991bc8862f0c994e) Change-Id: I0270a9a2f97c3b21087e280bb890159b43975e04 BUG: 1496317 Signed-off-by: Ravishankar N <ravishankar@redhat.com> Reported-by: Rahul Hinduja <rhinduja@redhat.com> Reported-by: Mabi <mabi@protonmail.ch>
* mount/fuse: Make event-history feature configurableKrutika Dhananjay2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and disable it by default. Backport of: > Change-Id: Ia533788d309c78688a315dc8cd04d30fad9e9485 > Reviewed-on: https://review.gluster.org/18242 > BUG: 1467614 > cherry-picked from commit 956d43d6e89d40ee683547003b876f1f456f03b6 This is because having it disabled seems to improve performance. This could be due to the lock contention by the different epoll threads on the circular buff lock in the fop cbks just before writing their response to /dev/fuse. Just to provide some data - wrt ovirt-gluster hyperconverged environment, I saw an increase in IOPs by 12K with event-history disabled for randrom read workload. Usage: mount -t glusterfs -o event-history=on $HOSTNAME:$VOLNAME $MOUNTPOINT OR glusterfs --event-history=on --volfile-server=$HOSTNAME --volfile-id=$VOLNAME $MOUNTPOINT Change-Id: Ia533788d309c78688a315dc8cd04d30fad9e9485 BUG: 1495397 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* features/shard: Change default shard-block-size to 64MBKrutika Dhananjay2017-09-286-0/+7
| | | | | | | | | | | | Backport of: > Change-Id: I55fa87e07136cff10b0d725ee24dd3151016e64e > BUG: 1489823 > Reviewed-on: https://review.gluster.org/18243 > cherry picked from commit e4a59b384f5bbaaeb937a53cef64f4e388f85153 Change-Id: I55fa87e07136cff10b0d725ee24dd3151016e64e BUG: 1492026 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* features/shard: Return aggregated size in stbuf of LINK fopKrutika Dhananjay2017-09-071-0/+25
| | | | | | | | | | | | | | | | Backport of: > Change-Id: I42df7679d63fec9b4c03b8dbc66c5625f097fac0 > Reviewed-on: https://review.gluster.org/18209 > BUG: 1488546 > cherry-picked from 91430817ce5bcbeabf057e9c978485728a85fb2b Change-Id: I42df7679d63fec9b4c03b8dbc66c5625f097fac0 BUG: 1488718 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com> Reviewed-on: https://review.gluster.org/18211 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
* feature/posix: Enabled gfid2path by defaultv3.12.0Kotresh HR2017-08-296-11/+5
| | | | | | | | | | | | | | | | | | | | | | | Enable gfid2path feature by default. The basic performance tests are carried out and it doesn't show significant depreciation. The results are updated in issue. Updates: #139 Change-Id: I5f1949a608d0827018ef9d548d5d69f3bb7744fd > Signed-off-by: Kotresh HR <khiremat@redhat.com> > Reviewed-on: https://review.gluster.org/17950 > Smoke: Gluster Build System <jenkins@build.gluster.org> > CentOS-regression: Gluster Build System <jenkins@build.gluster.org> > Reviewed-by: Aravinda VK <avishwan@redhat.com> > Reviewed-by: Amar Tumballi <amarts@redhat.com> (cherry picked from commit 3ec63650bb7fd874a5013e7be4a2def3b519c9b2) Reviewed-on: https://review.gluster.org/18133 Reviewed-by: Amar Tumballi <amarts@redhat.com> Smoke: Gluster Build System <jenkins@build.gluster.org> Tested-by: Shyamsundar Ranganathan <srangana@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
* glusterd: glusterd fails to start if peers file has blank lineGaurav Yadav2017-08-291-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: On start of glusterd service, glusterd fetch data from store, while parsing data from store if peers file consists of blank line glusterd fails to start. Fix: With this fix while parsing peers file glusterd will skip blank lines if it contains any. >Reviewed-on: https://review.gluster.org/18066 >Tested-by: Gaurav Yadav <gyadav@redhat.com> >Smoke: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: Prashanth Pai <ppai@redhat.com> >CentOS-regression: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: Atin Mukherjee <amukherj@redhat.com> >Reviewed-by: Niels de Vos <ndevos@redhat.com> Change-Id: I53cd65a54de5f57baef292b2118b70ffb7f99388 BUG: 1486107 Signed-off-by: Gaurav Yadav <gyadav@redhat.com> Reviewed-on: https://review.gluster.org/18124 Reviewed-by: Prashanth Pai <ppai@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
* glusterd: replace-brick executing successfully when quorum does not metGaurav Yadav2017-08-291-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | Problem: replace-brick command on a setup where quorum does not met executing successfully. Fix: With the fix glusterd is validating whether server is in quorum or not during replace-brick staging >Reviewed-on: https://review.gluster.org/18068 >Smoke: Gluster Build System <jenkins@build.gluster.org> >CentOS-regression: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: Atin Mukherjee <amukherj@redhat.com> Change-Id: I8017154bb62bdcc6c6490e720ecfe9cde090c161 BUG: 1486110 Signed-off-by: Gaurav Yadav <gyadav@redhat.com> Reviewed-on: https://review.gluster.org/18125 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Atin Mukherjee <amukherj@redhat.com> Reviewed-by: Prashanth Pai <ppai@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
* glusterd: disallow volume specific options to be set with all as volume nameAtin Mukherjee2017-08-211-0/+25
| | | | | | | | | | | | | | | | | | | | | | | All the .validate_fn defined in volume map entry table refers to volinfo object. And if we end up in trying to set a volume level option cluster wide glusterd results into a crash. >Reviewed-on: https://review.gluster.org/18052 >Smoke: Gluster Build System <jenkins@build.gluster.org> >Reviewed-by: Prashanth Pai <ppai@redhat.com> >Reviewed-by: mohammed rafi kc <rkavunga@redhat.com> >Reviewed-by: Gaurav Yadav <gyadav@redhat.com> >CentOS-regression: Gluster Build System <jenkins@build.gluster.org> >(cherry picked from commit 01abf7ee37702407403afcf9aa6c9019a0316e1d) Change-Id: I7c877aee0ff5c8c1d8c95662fdc8c8923355ae7b BUG: 1482804 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> Reviewed-on: https://review.gluster.org/18060 Reviewed-by: Prashanth Pai <ppai@redhat.com> Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
generated by cgit (git 2.34.1) at 2024-05-01 22:14:03 +0000