summaryrefslogtreecommitdiffstats
path: root/xlators/cluster/ec/src
Commit message (Collapse)AuthorAgeFilesLines
* Land part 2 of clang-format changesGluster Ant2018-09-1221-14016/+13766
| | | | | Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4 Signed-off-by: Nigel Babu <nigelb@redhat.com>
* Land clang-format changesGluster Ant2018-09-1214-1018/+1056
| | | | Change-Id: I6f5d8140a06f3c1b2d196849299f8d483028d33b
* ec-heal: remove a duplicate definition of alloca0Amar Tumballi2018-09-101-1/+0
| | | | | | | | | | the same macro is defined in common-utils.h, which seems to be much better place for the same. Updates: bz#1193929 Change-Id: I409b719c291102136500b955e5827a550142ed96 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* cluster/ec: Don't update trusted.ec.version if fop succeedsAshish Pandey2018-09-071-0/+9
| | | | | | | | | | | | | | | | | | | | If a fop has succeeded on all the bricks and trying to release the lock, there is no need to update the version for the file/entry. All it will do is to increase the version from x to x+1 on all the bricks. If this update (x to x+1) fails on some brick, this will indicate that the entry is unhealthy while in realty everything is fine with the entry. Avoiding this update will help to not to send one xattrop at the end of the fops. Which will decrease the chances of entries being in unhealthy state and also improve the performance. Change-Id: Id9fca6bd2991425db6ed7d1f36af27027accb636 fixes: bz#1623759 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: Improve logging for some critical error messagesAshish Pandey2018-09-073-14/+55
| | | | | | Change-Id: I037e52a3467467b81a1ba5416317870864060d4d updates: bz#1615703 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: Fix Coverity issueAshish Pandey2018-08-312-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | Fix following coverity issues- CID: 1382378 1382459 https://scan6.coverity.com/reports.htm#v42607/p10714/fileInstanceId=85091670&defectInstanceId=25915064&mergedDefectId=1382459 https://scan6.coverity.com/reports.htm#v42607/p10714/fileInstanceId=85091670&defectInstanceId=25915063&mergedDefectId=1382378 Problem: ASSERT_LOCAL(this, healer) function is supposed to get the local healer so that we can take advantage of it while healing and reading data. However, we are not using healer->local anywhere. Also, this is not as useful in context of EC as it is in AFR. In EC we have to raed fragments from 4 bricks to heal a bad fragment on other brick. Change-Id: Iea8ce127ea02cc84e3823cb2be82a47872217b33 updates: bz#789278 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* multiple files: remove unndeeded memset()Yaniv Kaul2018-08-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a squash of multiple commits: contrib/fuse-lib/misc.c: remove unneeded memset() All flock variables are properly set, no need to memset it. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I8e0512c5a88daadb0e587f545fdb9b32ca8858a2 libglusterfs/src/{client_t|fd|inode|stack}.c: remove some memset() I don't think there's a need for any of them. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I2be9ccc3a5cb5da51a92af73488cdabd1c527f59 libglusterfs/src/xlator.c: remove unneeded memset() All xl->mem_acct members are properly set, no need to memset it. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I7f264cd47e7a06255a3f3943c583de77ae8e3147 xlators/cluster/afr/src/afr-self-heal-common.c: remove unneeded memset() Since we are going over the whole array anyway, initialize it properly, to either 1 or 0. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: Ied4210388976b6a7a2e91cc3de334534d6fef201 xlators/cluster/dht/src/dht-common.c: remove unneeded memset() Since we are going over the whole array anyway it is initialized properly. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: Idc436d2bd0563b6582908d7cbebf9dbc66a42c9a xlators/cluster/ec/src/ec-helpers.c: remove unneeded memset() Since we are going over the whole array anyway it is initialized properly. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I81bf971f7fcecb4599e807d37f426f55711978fa xlators/mgmt/glusterd/src/glusterd-volgen.c: remove some memset() I don't think there's a need for any of them. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I476ea59ba53546b5153c269692cd5383da81ce2d xlators/mgmt/glusterd/src/glusterd-geo-rep.c: read() in 4K blocks The current 1K seems small. 4K is usually better (in Linux). Also remove a memset() that I don't think is needed between reads. Only compile-tested! Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I5fb7950c92d282948376db14919ad12e589eac2b xlators/storage/posix/src/posix-{gfid-path|inode-fd-ops}.c: remove memset() before sys_*xattr() functions. I don't see a reason to memset the array sent to the functions sys_llistxattr(), sys_lgetxattr(), sys_lgetxattr(), sys_flistxattr(), sys_fgetxattr(). (Note: it's unclear to me why we are calling sys_*txattr() functions with XATTR_VAL_BUF_SIZE-1 size instead of XATTR_VAL_BUF_SIZE ). Only compile-tested! Change-Id: Ief2103b56ba6c71e40ed343a93684eef6b771346 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* cluster/ec: Prevent a possible out-of-bounds readVijay Bellur2018-08-271-0/+1
| | | | | | | | | | | Addresses CID 1370939 In ec_code_x64_epilog(), there is a possibility of reading from an incorrect index of ec_code_x64_regmap array Change-Id: Ib8a228bbe13631188343634b2bde5919cdaab5a4 Updates: bz#789278 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
* multiple files: move from strlen() to sizeof()Yaniv Kaul2018-08-254-8/+8
| | | | | | | | | | | | {ec-heal|ec-combine|ec-helpers|ec-inode-read}.c For const strings, just do compile time size calc instead of runtime. Compile-tested only! Change-Id: If92ba0a7a20f64b898d01c6e3b6708190ca93e04 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* cluster/ec: FORWARD_NULL coverity fixSunil Kumar Acharya2018-08-162-1/+5
| | | | | | | | | | | Fixing FORWARD_NULL coverify errors with EC. CID: 1394650 BUG: 789278 Change-Id: I52c99dac3483ca31a86cd7e3a959d4010b195f32 updates: bz#789278 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* coverity: Ignore most of SECURE_TEMP issuesShyamsundarR2018-07-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | mkstemp as per the Linux man page, uses 0600 as the permission bits when creating the file. This is hence safe and a Coverity warning that should be ignored. Further, we are mostly a multi-threaded program in all our daemons and cannot set and unset umask at will in a multi-threaded program, to address the coverity issue. This change attempts to nudge coverity to ignore this warning, using the pattern, /* coverity[EVENT_TAG_NAME] ... */ <line of code that has the issue> This commit is an experiment, if post merge the next coverity report ignores these errors, the above pattern (as found using an internet search) works and can be applied to certain other warnings as well. Change-Id: I73a184ce1a54dd9e66542952b1190a74438c826a Updates: bz#789278 Signed-off-by: ShyamsundarR <srangana@redhat.com>
* All: run codespell on the code and fix issues.Yaniv Kaul2018-07-229-9/+9
| | | | | | | | | | | | Please review, it's not always just the comments that were fixed. I've had to revert of course all calls to creat() that were changed to create() ... Only compile-tested! Change-Id: I7d02e82d9766e272a7fd9cc68e51901d69e5aab5 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* md-cache: Do not invalidate cache post set/remove xattrPoornima G2018-07-111-0/+63
| | | | | | | | | | | | | | | Since setxattr and removexattr fops cbk do not carry poststat, the stat cache was being invalidated in setxatr/remoxattr cbk. Hence the further lookup wouldn't be served from cache. To prevent this invalidation, md-cache is modified to get the poststat in set/removexattr_cbk in dict. Co-authored with Xavi Hernandez. Change-Id: I6b946be2d20b807e2578825743c25ba5927a60b4 fixes: bz#1586018 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Signed-off-by: Poornima G <pgurusid@redhat.com>
* afr,ec: Print if the subvolume is up in statedumpPranith Kumar K2018-07-031-0/+1
| | | | | | fixes bz#1597156 Change-Id: I323eb9190e40b12df216698dcdba74a6d336beeb Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/ec: Fix pre-op xattrop managementXavi Hernandez2018-05-233-32/+66
| | | | | | | | | | | | | | | | | | | | Multiple pre-op xattrop can be simultaneously being processed. On the cbk it was checked if the fop was waiting for some specific data (like size and version) and, if so, it was assumed that this answer should contain that data. This is not true, since a fop can be waiting for some data, but it may come from the xattrop of another fop. This patch differentiates between needing some information and providing it. This is related to parallel writes. Disabling them fixed the problem, but also prevented concurrent reads. A change has been made so that disabling parallel writes still allows parallel reads. Fixes: bz#1578325 Change-Id: I74772ad6b80b7b37805da93d5ec3ae099e96b041 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* libglusterfs: Capture the dict response in syncop_xattrop_cbkkarthik-us2018-04-271-1/+1
| | | | | | | | | | | | | | | Problem: Currently it is not possible to capture the xattrs values which are set on the bricks by calling syncop_(f)xattrop, because the response dict is not being assigned to any of the dictionaries. Fix: In the xattrop callback capture the response dict and send it back to the caller if it is requested. Change-Id: I9de9bcd97d6008091c9b060bcca3676cb9ae8ef9 fixes: bz#1572076 Signed-off-by: karthik-us <ksubrahm@redhat.com>
* cluster/ec: Turn ON the stripe-cache option by defaultAshish Pandey2018-04-061-1/+1
| | | | | | Change-Id: I0a290396c30c635b13ee73004d20259efb76a954 fixes: bz#1563945 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: send list-node-uuids request to all subvolumesXavi Hernandez2018-03-281-1/+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. Change-Id: If62eb39a6857258923ba625e153d4ad79018ea2f fixes: bz#1561406 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* cluster/ec: fix SHD crash for null gfid'sXavi Hernandez2018-03-211-0/+8
| | | | | | | | | | | | | | | | | | | When the self-heal daemon is doing a full sweep it uses readdirp to get extra stat information from each file. This information is obtained in two steps by the posix xlator: first the directory is read to get the entries and then each entry is stated to get additional info. Between these two steps, it's possible that the file is removed by the user, so we'll get an error, leaving stat info empty. EC's heal daemon was using the gfid blindly, causing an assert failure when protocol/client was trying to encode the gfid. To fix the problem a check has been added. If we detect a null gfid, we simply ignore it and continue healing. Change-Id: I2e4acdcecd0b6951055e50d1c37d686a2186a228 BUG: 1558016 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* cluster/ec: Change default read policy to gfid-hashAshish Pandey2018-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cluster/ec: avoid delays in self-healXavi Hernandez2018-03-144-48/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Change-Id: I58d9ab6ef17b30f704dc322e1d3d53b904e5f30e BUG: 1547662 Signed-off-by: Xavi Hernandez <jahernan@redhat.com>
* cluster/ec: Do lock conflict check correctly for wait-listPranith Kumar K2018-02-011-8/+15
| | | | | | | | | | | | | | Problem: ec_link_has_lock_conflict() is traversing over only owner_list but the function is also getting called with wait_list. Fix: Modify ec_link_has_lock_conflict() to traverse lists correctly. Updated the callers to reflect the changes. BUG: 1540669 Change-Id: Ibd7ea10f4498e7c2761f9a6faac6d5cb7d750c91 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/ec : EC options for GD2Sunil Kumar Acharya2018-01-221-1/+34
| | | | | | | Updates #302 Change-Id: I31b4648f7b1a394fceece5cba8120c579c66edd9 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* locks: added inodelk/entrylk contention upcall notificationsXavier Hernandez2018-01-164-94/+239
| | | | | | | | | | | | | | The locks xlator now is able to send a contention notification to the current owner of the lock. This is only a notification that can be used to improve performance of some client side operations that might benefit from extended duration of lock ownership. Nothing is done if the lock owner decides to ignore the message and to not release the lock. For forced release of acquired resources, leases must be used. Change-Id: I7f1ad32a0b4b445505b09908a050080ad848f8e0 Signed-off-by: Xavier Hernandez <xhernandez@datalab.es>
* cluster/ec: OpenFD heal implementation for ECSunil Kumar Acharya2018-01-057-91/+243
| | | | | | | | | | | | | 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. BUG: 1431955 Change-Id: Ib696f59c41ffd8d5678a484b23a00bb02764ed15 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* posix: Introduce flags for validity of iatt membersRavishankar N2017-12-291-2/+2
| | | | | | | | | | | | | | | | | | v1 of the patch started off as adding new fields to iatt that can be filled up using statx but the discussions were more around introducing masks to check the validity of different fields from a RIO perspective. To that extent, I have dropped the statx call in this version and introduced a 64 bit mask for existing fields. The masks I have defined are similar with the statx() flags' masks. I have *not* changed iatt_to_stat() to use the macros IATT_TYPE_VALID, IATT_GFID_VALID etc before blindly copying from struct iatt to struct. Also fixed warnings in xlators because of atime/mtime/ctime seconds field change from uint32_t to int64_t. Change-Id: I4ac614f1e8d5c8246fc99d5bc2d2a23e7941512b Signed-off-by: Ravishankar N <ravishankar@redhat.com>
* cluster/ec: Fix possible shift overflowXavier Hernandez2017-12-223-10/+12
| | | | | | | | | | A coverity scan has revelaed a potential shift overflow while scanning the bitmap of available subvolumes. The actual overflow cannot happen, but I've changed to test used to control the limit to make it explicit. Change-Id: Ieb55f010bbca68a1d86a93e47822f7c709a26e83 BUG: 789278 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* cluster/ec: Change [f]getxattr to parallel-dispatch-onePranith Kumar K2017-12-224-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment in EC, [f]getxattr operations wait to acquire a lock while other operations are in progress even when it is in the same mount with a lock on the file/directory. This happens because [f]getxattr operations follow the model where the operation is wound on 'k' of the bricks and are matched to make sure the data returned is same on all of them. This consistency check requires that no other operations are on-going while [f]getxattr operations are wound to the bricks. We can perform [f]getxattr in another way as well, where we find the good_mask from the lock that is already granted and wind the operation on any one of the good bricks and unwind the answer after adjusting size/blocks to the parent xlator. Since we are taking into account good_mask, the reply we get will either be before or after a possible on-going operation. Using this method, the operation doesn't need to depend on completion of on-going operations which could be taking long time (In case of some slow disks and writes are in progress etc). Thus we reduce the time to serve [f]getxattr requests. I changed [f]getxattr to dispatch-one and added extra logic in ec_link_has_lock_conflict() to not have any conflicts for fops with EC_MINIMUM_ONE as fop->minimum to achieve the effect described above. Modified scripts to make sure READ fop is received in EC to trigger heals. Updates gluster/glusterfs#368 Change-Id: I3b4ebf89181c336b7b8d5471b0454f016cdaf296 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/ec: Add default value for the redundancy optionKamal Mohanan2017-12-211-0/+1
| | | | | | | Updates #302 Change-Id: Ifccc6a64c2b2a3b3a0133e6c8042cdf61a0838ce Signed-off-by: Kamal Mohanan <kmohanan@redhat.com>
* all: Simplify component message id's definitionXavier Hernandez2017-12-141-572/+88
| | | | | | | | | This patch creates a new way of defining message id's that is easier and less error prone because it doesn't require so many manual changes each time a new component is defined or a new message created. Change-Id: I71ba8af9ac068f5add7e74f316a2478bc991c67b Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* cluster/ec: Fix bugs in stripe-cache featureAshish Pandey2017-12-052-1/+4
| | | | | | | | | | | | | | 1 - This patch fixes a bug in ec_update_stripe() that prevented some stripes to be updated after a write. 2 - This patch also include code modification for the case in which a file does not exist and we write on unaligned offset and user size, the last stripe on which "end" will fall should also be cached. Change-Id: I069cb4be1c8d59c206e3b35a6991e1fbdbc9b474 BUG: 1520758 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: EC DISCARD doesn't punch hole properlySunil Kumar Acharya2017-11-281-2/+4
| | | | | | | | | | | | | | Problem: DISCARD operation on EC volume was punching hole of lesser size than the specified size in some cases. Solution: EC was not handling punch hole for tail part in some cases. Updated the code to handle it appropriately. BUG: 1516206 Change-Id: If3e69e417c3e5034afee04e78f5f78855e65f932 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: Prevent self-heal to work after PARENT_DOWNXavier Hernandez2017-11-282-28/+52
| | | | | | | | | | | | | | | | | | | When the volume is being stopped, PARENT_DOWN event is received. This instructs EC to wait until all pending operations are completed before declaring itself down. However heal operations are ignored and allowed to continue even after having said it was down. This may cause unexpected results and crashes. To solve this, heal operations are considered exactly equal as any other operation and EC won't propagate PARENT_DOWN until all operations, including healing, are complete. To avoid big delays if this happens in the middle of a big heal, a check has been added to quit current heal if shutdown is detected. Change-Id: I26645e236ebd115eb22c7ad4972461111a2d2034 BUG: 1515266 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* ec: Use tiebreaker_inodelk where necessaryPranith Kumar K2017-11-221-8/+11
| | | | | | | | | | | | | | | | | When there are big directories or files that need to be healed, other shds are stuck on getting lock on self-heal domain for these directories/files. If there is a tie-breaker logic, other shds can heal some other files/directories while 1 of the shds is healing the big file/directory. Before this patch: 96.67 4890.64 us 12.89 us 646115887.30us 340869 INODELK After this patch: 40.76 42.35 us 15.09 us 6546.50us 438478 INODELK Fixes gluster/glusterfs#354 Change-Id: Ia995b5576b44f770c064090705c78459e543cc64 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/ec: Fix op-version for disperse.other-eager-lockXavier Hernandez2017-11-141-1/+1
| | | | | | | | | The op-version used for the new option was wrong. It has been set to 3.13.0. Change-Id: I88fbd7834e4a8018c8906303e734c251e90be8cf BUG: 1502610 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* cluster/ec: Keep last written strip in in-memory cacheAshish Pandey2017-11-108-84/+519
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Consider an EC volume with configuration 4 + 2. The stripe size for this would be 512 * 4 = 2048. That means, 2048 bytes of user data stored in one stripe. Let's say 2048 + 512 = 2560 bytes are already written on this volume. 512 Bytes would be in second stripe. Now, if there are sequential writes with offset 2560 and of size 1 Byte, we have to read the whole stripe, encode it with 1 Byte and then again have to write it back. Next, write with offset 2561 and size of 1 Byte will again READ-MODIFY-WRITE the whole stripe. This is causing bad performance because of lots of READ request travelling over the network. There are some tools and scenario's where such kind of load is coming and users are not aware of that. Example: fio and zip Solution: One possible solution to deal with this issue is to keep last stripe in memory. This way, we need not to read it again and we can save READ fop going over the network. Considering the above example, we have to keep last 2048 bytes (maximum) in memory per file. Change-Id: I3f95e6fc3ff81953646d374c445a40c6886b0b85 BUG: 1471753 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: UNUSED_VALUE coverity fixSunil Kumar Acharya2017-11-081-0/+4
| | | | | | | | | | Problem: Return values are not used. Solution: Removed the unused values. BUG: 789278 Change-Id: Ica2b95bb659dfc7ec5346de0996b9d2fcd340f8d Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: REVERSE_INULL coverity fixSunil Kumar Acharya2017-11-081-2/+1
| | | | | | | | | | Problem: fop could be NULL. Solution: Check has been added to verify fop. BUG: 789278 Change-Id: I7e8d2c1bdd8960c609aa485f180688a95606ebf7 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: NEGATIVE_RETURNS coverity fixSunil Kumar Acharya2017-11-071-0/+5
| | | | | | | | | | Problem: Source could be negative. Solution: Check has been added to verify the same. BUG: 789278 Change-Id: I8cca6297327e7923b25949c20ec8d1a711207a76 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: FORWARD_NULL coverity fixSunil Kumar Acharya2017-11-071-4/+6
| | | | | | | | | | Problem: xattr could be NULL. Solution: Added check to verify the same. BUG: 789278 Change-Id: Ie013f5655f4621434e5023dd76cef44b976adc68 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: Remove possibility of NULL derefAshish Pandey2017-11-051-1/+1
| | | | | | | | | | | | | Coverity ID: 237 Problem: In ec_check_status we are trying to deref fop->answer which could be NULL. Solution: Check Null condition before using this pointer. Change-Id: I4f9a73dc2f062ca9c62b4c4baf0a6fcadade88f2 BUG: 789278 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: create eager-lock option for non-regular filesXavier Hernandez2017-11-053-13/+47
| | | | | | | | | A new option is added to allow independent configuration of eager locking for regular files and non-regular files. Change-Id: I8f80e46d36d8551011132b15c0fac549b7fb1c60 BUG: 1502610 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* cluster/ec: FORWARD_NULL coverity fixSunil Kumar Acharya2017-11-012-0/+5
| | | | | | | | | | Problem: cbk could be NULL. Solution: Assigned appropriate value to cbk. BUG: 789278 Change-Id: I2e4bba9a54f965c6a7bccf0b0cb6c5f75399f6e6 Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: MISSING_BREAK coverity fixSunil Kumar Acharya2017-10-311-0/+3
| | | | | | | | | | Problem: switch case syntax issue. Solution: syntax fixed. BUG: 789278 Change-Id: I76da72c3ab6ffc5db671686a71d6a596beaf496e Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: Implement DISCARD FOP for ECSunil Kumar Acharya2017-10-255-48/+332
| | | | | | | | | | | Updates #254 This code change implements DISCARD FOP support for EC. BUG: 1461018 Change-Id: I09a9cb2aa9d91ec27add4f422dc9074af5b8b2db Signed-off-by: Sunil Kumar Acharya <sheggodu@redhat.com>
* cluster/ec: Allow parallel writes in EC if possiblePranith Kumar K2017-10-248-142/+282
| | | | | | | | | | | | | | | | | | Problem: Ec at the moment sends one modification fop after another, so if some of the disks become slow, for a while then the wait time for the writes that are waiting in the queue becomes really bad. Fix: Allow parallel writes when possible. For this we need to make 3 changes. 1) Each fop now has range parameters they will be updating. 2) Xattrop is changed to handle parallel xattrop requests where some would be modifying just dirty xattr. 3) Fops that refer to size now take locks and update the locks. Fixes #251 Change-Id: Ibc3c15372f91bbd6fb617f0d99399b3149fa64b2 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* cluster/ec: Coverity Fix UNUSED_VALUE in ec_create_nameKamal Mohanan2017-10-161-1/+1
| | | | | | | | | | | | | Problem: The value returned by cluster_mkdir is assigned to ret at ec-heal.c:1076. But this value is overwritten before it can be used. Solution: The return value of cluster_mkdir is ignored. It is not assigned to ret. Change-Id: Iee6b8d8b04e0bd800dd30d2c24cab755b9e63443 BUG: 789278 Signed-off-by: Kamal Mohanan <kmohanan@redhat.com>
* cluster/ec: Improve heal info command to handle obvious casesAshish Pandey2017-10-163-24/+41
| | | | | | | | | | | | | | | | | | | | | | | | | Problem: 1 - If a brick is down and we see an index entry in .glusterfs/indices, we should show it in heal info output as it most certainly needs heal. 2 - The first problem is also not getting handled after ec_heal_inspect. Even if in ec_heal_inspect, lookup will mark need_heal as true, we don't handle it properly in ec_get_heal_info and continue with locked inspect which takes lot of time. Solution: 1 - In first case we need not to do any further invstigation. As soon as we see that a brick is down, we should say that this index entry needs heal for sure. 2 - In second case, if we have need_heal as _gf_true after ec_heal_inspect, we should show it as heal requires. Change-Id: Ibe7f9d7602cc0b382ba53bddaf75a2a2c3326aa6 BUG: 1476668 Signed-off-by: Ashish Pandey <aspandey@redhat.com>
* cluster/ec: add functions for stripe alignmentXavier Hernandez2017-10-136-47/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes old functions to align offsets and sizes to stripe size boundaries and adds new ones to offer more possibilities. The new functions are: * ec_adjust_offset_down() Aligns a given offset to a multiple of the stripe size equal or smaller than the initial one. It returns the size of the gap between the aligned offset and the given one. * ec_adjust_offset_up() Aligns a given offset to a multiple of the stripe size equal or greater than the initial one. It returns the size of the skipped region between the given offset and the aligned one. If an overflow happens, the returned valid has negative sign (but correct value) and the offset is set to the maximum value (not aligned). * ec_adjust_size_down() Aligns the given size to a multiple of the stripe size equal or smaller than the initial one. It returns the size of the missed region between the aligned size and the given one. * ec_adjust_size_up() Aligns the given size to a multiple of the stripe size equal or greater than the initial one. It returns the size of the gap between the given size and the aligned one. If an overflow happens, the returned value has negative sign (but correct value) and the size is set to the maximum value (not aligned). These functions have been defined in ec-helpers.h as static inline since they are very small and compilers can optimize them (specially the 'scale' argument). Change-Id: I4c91009ad02f76c73772034dfde27ee1c78a80d7 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* cluster/ec: Handle parallel get_size_versionPranith Kumar K2017-10-103-59/+102
| | | | | | Updates #251 Change-Id: I6244014dbc90af3239d63d75a064ae22ec12a054 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
generated by cgit (git 2.34.1) at 2024-11-18 05:26:05 +0000