summaryrefslogtreecommitdiffstats
path: root/libglusterfs
Commit message (Collapse)AuthorAgeFilesLines
* event: rename event_XXX with gf_ prefixedXiubo Li2019-08-213-40/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I hit one crash issue when using the libgfapi. In the libgfapi it will call glfs_poller() --> event_dispatch() in file api/src/glfs.c:721, and the event_dispatch() is defined by libgluster locally, the problem is the name of event_dispatch() is the extremly the same with the one from libevent package form the OS. For example, if a executable program Foo, which will also use and link the libevent and the libgfapi at the same time, I can hit the crash, like: kernel: glfs_glfspoll[68486]: segfault at 1c0 ip 00007fef006fd2b8 sp 00007feeeaffce30 error 4 in libevent-2.0.so.5.1.9[7fef006ed000+46000] The link for Foo is: lib_foo_LADD = -levent $(GFAPI_LIBS) It will crash. This is because the glfs_poller() is calling the event_dispatch() from the libevent, not the libglsuter. The gfapi link info : GFAPI_LIBS = -lacl -lgfapi -lglusterfs -lgfrpc -lgfxdr -luuid If I link Foo like: lib_foo_LADD = $(GFAPI_LIBS) -levent It will works well without any problem. And if Foo call one private lib, such as handler_glfs.so, and the handler_glfs.so will link the GFAPI_LIBS directly, while the Foo won't and it will dlopen(handler_glfs.so), then the crash will be hit everytime. The link info will be: foo_LADD = -levent libhandler_glfs_LIBADD = $(GFAPI_LIBS) I can avoid the crash temporarily by linking the GFAPI_LIBS in Foo too like: foo_LADD = $(GFAPI_LIBS) -levent libhandler_glfs_LIBADD = $(GFAPI_LIBS) But this is ugly since the Foo won't use any APIs from the GFAPI_LIBS. And in some cases when the --as-needed link option is added(on many dists it is added as default), then the crash is back again, the above workaround won't work. Backport of: > https://review.gluster.org/#/c/glusterfs/+/23110/ > Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa > Fixes: #699 > Signed-off-by: Xiubo Li <xiubli@redhat.com> Change-Id: I38f0200b941bd1cff4bf3066fca2fc1f9a5263aa updates: bz#1740519 Signed-off-by: Xiubo Li <xiubli@redhat.com> (cherry picked from commit 799edc73c3d4f694c365c6a7c27c9ab8eed5f260)
* ctime: Set mdata xattr on legacy filesKotresh HR2019-08-195-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The files which were created before ctime enabled would not have "trusted.glusterfs.mdata"(stores time attributes) xattr. Upon fops which modifies either ctime or mtime, the xattr gets created with latest ctime, mtime and atime, which is incorrect. It should update only the corresponding time attribute and rest from backend Solution: Creating xattr with values from brick is not possible as each brick of replica set would have different times. So create the xattr upon successful lookup if the xattr is not created Note To Reviewers: The time attributes used to set xattr is got from successful lookup. Instead of sending the whole iatt over the wire via setxattr, a structure called mdata_iatt is sent. The mdata_iatt contains only time attributes. Backport of: > Patch: https://review.gluster.org/22936 > Change-Id: I5e535631ddef04195361ae0364336410a2895dd4 > BUG: 1593542 > Signed-off-by: Kotresh HR <khiremat@redhat.com> Change-Id: I5e535631ddef04195361ae0364336410a2895dd4 updates: bz#1739430 Signed-off-by: Kotresh HR <khiremat@redhat.com>
* glusterd/svc: update pid of mux volumes from the shd processMohammed Rafi KC2019-07-243-8/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a normal volume, we are updating the pid from a the process while we do a daemonization or at the end of the init if it is no-daemon mode. Along with updating the pid we also lock the file, to make sure that the process is running fine. With brick mux, we were updating the pidfile from gluterd after an attach/detach request. There are two problems with this approach. 1) We are not holding a pidlock for any file other than parent process. 2) There is a chance for possible race conditions with attach/detach. For example, shd start and a volume stop could race. Let's say we are starting an shd and it is attached to a volume. While we trying to link the pid file to the running process, this would have deleted by the thread that doing a volume stop. Backport of : https://review.gluster.org/#/c/glusterfs/+/22935/ >Change-Id: I29a00352102877ce09ea3f376ca52affceb5cf1a >Updates: bz#1722541 >Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com> Change-Id: I29a00352102877ce09ea3f376ca52affceb5cf1a Updates: bz#1732668 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* graph/shd: Use top down approach while cleaning xlatorMohammed Rafi KC2019-07-241-1/+9
| | | | | | | | | | | | | | | | | | | We were cleaning xlator from botton to top, which might lead to problems when upper xlators trying to access the xlator object loaded below. One such scenario is when fd_unref happens as part of the fini call which might lead to calling the releasedir to lower xlator. This will lead to invalid mem access Backport of:https://review.gluster.org/#/c/glusterfs/+/22968/ >Change-Id: I8a6cb619256fab0b0c01a2d564fc88287c4415a0 >Updates: bz#1716695 >Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com> Change-Id: I8a6cb619256fab0b0c01a2d564fc88287c4415a0 Updates: bz#1730229 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* graph/shd: Use glusterfs_graph_deactivate to free the xl recMohammed Rafi KC2019-07-242-2/+9
| | | | | | | | | | | | | | | | | We were using glusterfs_graph_fini to free the xl rec from glusterfs_process_volfp as well as glusterfs_graph_cleanup. Instead we can use glusterfs_graph_deactivate, which is does fini as well as other common rec free. Backportof : https://review.gluster.org/22904 >Change-Id: Ie4a5f2771e5254aa5ed9f00c3672a6d2cc8e4bc1 >Updates: bz#1716695 >Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com> Change-Id: Ie4a5f2771e5254aa5ed9f00c3672a6d2cc8e4bc1 Updates: bz#1730229 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* core: fix deadlock between statedump and fd_anonymous()Xavi Hernandez2019-07-201-76/+61
| | | | | | | | | | | | | | | | | | There exists a deadlock between statedump generation and fd_anonymous() function because they are acquiring inode table lock and inode lock in reverse order. This patch modifies fd_anonymous() so that it takes inode lock only when it's really necessary, avoiding the deadlock. Backport of: > Change-Id: I24355447f0ea1b39e2546782ad07f0512cc381e7 > BUG: 1727068 > Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Change-Id: I24355447f0ea1b39e2546782ad07f0512cc381e7 Fixes: bz#1729950 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* core: replace inet_addr with inet_ptonRinku Kothiya2019-06-241-1/+7
| | | | | | | | | | Fixes warning raised by RPMDiff on the use of inet_addr, which may impact Ipv6 support fixes: bz#1721385 Change-Id: Id2d9afa1747efa64bc79d90dd2566bff54deedeb Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
* core: fedora 30 compiler warningsSheetalPamecha2019-06-181-1/+1
| | | | | | | | warning: ‘%s’ directive argument is null [-Wformat-overflow=] Change-Id: I69b8d47f0002c58b00d1cc947fac6f1c64e0b295 updates: bz#1193929 Signed-off-by: SheetalPamecha <spamecha@redhat.com>
* core: improve timer accuracyXavier Hernandez2019-06-172-80/+59
| | | | | | | | Also fixed some issues on test ec-1468261.t. Change-Id: If156f86af986d9eed13cdd1f15c5a7214cd11706 Updates: bz#1193929 Signed-off-by: Xavier Hernandez <jahernan@redhat.com>
* multiple files: another attempt to remove includesYaniv Kaul2019-06-1436-119/+55
| | | | | | | | | | | | | | | | | | There are many include statements that are not needed. A previous more ambitious attempt failed because of *BSD plafrom (see https://review.gluster.org/#/c/glusterfs/+/21929/ ) Now trying a more conservative reduction. It does not solve all circular deps that we have, but it does reduce some of them. There is just too much to handle reasonably (dht-common.h includes dht-lock.h which includes dht-common.h ...), but it does reduce the overall number of lines of include we need to look at in the future to understand and fix the mess later one. Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* libglusterfs: cleanup iovec functionsXavi Hernandez2019-06-111-64/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch cleans some iovec code and creates two additional helper functions to simplify management of iovec structures. iov_range_copy(struct iovec *dst, uint32_t dst_count, uint32_t dst_offset, struct iovec *src, uint32_t src_count, uint32_t src_offset, uint32_t size); This function copies up to 'size' bytes from 'src' at offset 'src_offset' to 'dst' at 'dst_offset'. It returns the number of bytes copied. iov_skip(struct iovec *iovec, uint32_t count, uint32_t size); This function removes the initial 'size' bytes from 'iovec' and returns the updated number of iovec vectors remaining. The signature of iov_subset() has also been modified to make it safer and easier to use. The new signature is: iov_subset(struct iovec *src, int src_count, uint32_t start, uint32_t size, struct iovec **dst, int32_t dst_count); This function creates a new iovec array containing the subset of the 'src' vector starting at 'start' with size 'size'. The resulting array is allocated if '*dst' is NULL, or copied to '*dst' if it fits (based on 'dst_count'). It returns the number of iovec vectors used. A new set of functions to iterate through an iovec array have been created. They can be used to simplify the implementation of other iovec-based helper functions. Change-Id: Ia5fe57e388e23392a8d6cdab17670e337cadd587 Updates: bz#1193929 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* xlator/log: Add more logging in xlator_is_cleanup_startingMohammed Rafi KC2019-06-081-3/+9
| | | | | | | | This patch will add two extra logs for invalid argument Change-Id: I3950b4f4b9d88b1f1e788ef93d8f09d4bd8d4d8b updates: bz#1703948 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* across: clang-scan: fix NULL dereferencing warningsAmar Tumballi2019-06-041-1/+1
| | | | | | | | | All these checks are done after analyzing clang-scan report produced by the CI job @ https://build.gluster.org/job/clang-scan updates: bz#1622665 Change-Id: I590305af4ceb779be952974b2a36066ffc4865ca Signed-off-by: Amar Tumballi <amarts@redhat.com>
* features/shard: Fix block-count accounting upon truncate to lower sizeKrutika Dhananjay2019-06-041-0/+2
| | | | | | | | | | | | | | | | | The way delta_blocks is computed in shard is incorrect, when a file is truncated to a lower size. The accounting only considers change in size of the last of the truncated shards. FIX: Get the block-count of each shard just before an unlink at posix in xdata. Their summation plus the change in size of last shard (from an actual truncate) is used to compute delta_blocks which is used in the xattrop for size update. Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53 fixes: bz#1705884 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
* glusterd: Optimize code to copy dictionary in handshake code pathMohit Agrawal2019-05-313-5/+8
| | | | | | | | | | | | | Problem: While high no. of volumes are configured around 2000 glusterd has bottleneck during handshake at the time of copying dictionary Solution: To avoid the bottleneck serialize a dictionary instead of copying key-value pair one by one Change-Id: I9fb332f432e4f915bc3af8dcab38bed26bda2b9a fixes: bz#1711297 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* glusterd/shd: Optimize the glustershd manager to send reconfigureMohammed Rafi KC2019-05-311-1/+0
| | | | | | | | | | | | | Traditionally all svc manager will execute process stop and then followed by start each time when they called. But that is not required by shd, because the attach request implemented in the shd multiplex has the intelligence to check whether a detach is required prior to attaching the graph. So there is no need to send an explicit detach request if we are sure that the next call is an attach request Change-Id: I9157c8dcaffdac038f73286bcf5646a3f1d3d8ec fixes: bz#1710054 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* glusterfsd/cleanup: Protect graph object under a lockMohammed Rafi KC2019-05-312-27/+47
| | | | | | | | | | | While processing a cleanup_and_exit function, we are accessing a graph object. But this has not been protected under a lock. Because a parallel cleanup of a graph is quite possible which might lead to an invalid memory access Change-Id: Id05ca70d5b57e172b0401d07b6a1f5386c044e79 fixes: bz#1708926 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* stack: Make sure to have unique call-stacks in all casesPranith Kumar K2019-05-301-0/+2
| | | | | | | | | | | | | | | At the moment new stack doesn't populate frame->root->unique in all cases. This makes it difficult to debug hung frames by examining successive state dumps. Fuse and server xlators populate it whenever they can, but other xlators won't be able to assign 'unique' when they need to create a new frame/stack because they don't know what 'unique' fuse/server xlators already used. What we need is for unique to be correct. If a stack with same unique is present in successive statedumps, that means the same operation is still in progress. This makes 'finding hung frames' part of debugging hung frames easier. fixes bz#1714098 Change-Id: I3e9a8f6b4111e260106c48a2ac3a41ef29361b9e Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* tests: add tests for different signal handlingAmar Tumballi2019-05-302-0/+4
| | | | | | | | | | | Also some cleanup: * old-protocol.t was actually added to make sure we have line-coverage * first-test.t should have been removed as per the comment. It doesn't do anything. * add statvfs to rpc-coverage so we can cover statvfs in few xlators. updates: bz#1693692 Change-Id: Ie8651ce007de484c4abced16b4de765aa5e517be Signed-off-by: Amar Tumballi <amarts@redhat.com>
* Fix some "Null pointer dereference" coverity issuesXavi Hernandez2019-05-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | This patch fixes the following CID's: * 1124829 * 1274075 * 1274083 * 1274128 * 1274135 * 1274141 * 1274143 * 1274197 * 1274205 * 1274210 * 1274211 * 1288801 * 1398629 Change-Id: Ia7c86cfab3245b20777ffa296e1a59748040f558 Updates: bz#789278 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* inode: fix wrong loop count in __inode_ctx_freeXie Changlong2019-05-231-5/+6
| | | | | | | | Avoid serious memory leak fixes: bz#1711240 Change-Id: Ic61a8fdd0e941e136c98376a87b5a77fa8c22316 Signed-off-by: Xie Changlong <xiechanglong@cmss.chinamobile.com>
* ec/fini: Fix race with ec_fini and ec_notifyMohammed Rafi KC2019-05-213-0/+25
| | | | | | | | | | | | | | | During a graph cleanup, we first sent a PARENT_DOWN and wait for a child down to ultimately free the xlator and the graph. In the ec xlator, we cleanup the threads when we get a PARENT_DOWN event. But a racing event like CHILD_UP or event xl_op may trigger healing threads after threads cleanup. So there is a chance that the threads might access a freed private variabe Change-Id: I252d10181bb67b95900c903d479de707a8489532 fixes: bz#1703948 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* ec/shd: Cleanup self heal daemon resources during ec finiMohammed Rafi KC2019-05-131-0/+2
| | | | | | | | | | We were not properly cleaning self-heal daemon resources during ec fini. With shd multiplexing, it is absolutely necessary to cleanup all the resources during ec fini. Change-Id: Iae4f1bce7d8c2e1da51ac568700a51088f3cc7f2 fixes: bz#1703948 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* libglusterfs: Remove decompunder helper routines from symbol exportAnoop C S2019-05-111-4/+0
| | | | | | | | | | | | | decompounder and related sources were removed via the following commits: https://review.gluster.org/#/c/glusterfs/+/22627/ https://review.gluster.org/#/c/glusterfs/+/22629/ Therefore taking out symbol exports for those removed routines. Change-Id: I2ef99a318de1e4b512cabd2fa923225c5b79b1e5 updates: bz#1193929 Signed-off-by: Anoop C S <anoopcs@redhat.com>
* core: Capture process memory usage at the time of call gf_msg_nomemMohit Agrawal2019-05-111-9/+13
| | | | | | | | | | | | | Problem: All gluster processes call gf_mgm_nomem while calloc/malloc/realloc throw an error but the message does not capture current memory usage of gluster process Solution: Call getrusage to capture current memory usage of gluster process Change-Id: I2e0319da1f33b177fa042fdc9e7268068576c9c3 fixes: bz#1708051 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* glusterd/store: store all key-values in one shotYaniv Kaul2019-05-083-0/+51
| | | | | | | | | | | | Instead of saving each key-value separately, which is slow ( especially as we fflush() after each!), store them all as one string and write all together. Implements https://github.com/gluster/glusterfs/issues/629 Change-Id: Ie77a272446b0b6785584b710a4fdd9c613dd9578 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat,.com>
* libglusterfs: Fix compilation when --disable-mempool is usedPranith Kumar K2019-05-071-0/+5
| | | | | | updates bz#1193929 Change-Id: I245c065b209bcce5db939b6a0a934ba6fd393b47 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* mem-pool.{c|h}: minor changesYaniv Kaul2019-05-061-25/+12
| | | | | | | | | | | 1. Removed some code that was not needed. It did not really do anything. 2. CALLOC -> MALLOC in one place. Compile-tested only! updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I4419161e1bb636158e32b5d33044b06f1eef2449
* tests: validate volfile grammar - strings in volfileAmar Tumballi2019-05-064-85/+17
| | | | | | | | * libglusterfs/graph-print: remove unused code updates: bz#1693692 Change-Id: Iae81bb6a3af5911c3da07ab8f1d8f58f27e06905 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* options.c,h: minor changes to GF_OPTION_RECONFYaniv Kaul2019-04-302-49/+26
| | | | | | | | | | | Minor code changes (less variables and if statements) and use dict_get_strn(), since all options are fixed strings. Similar changes could be done to GF_OPTION_INIT() as well. Change-Id: I4a523f67183f4c4852a3d4de5e3cac52df68d3cf updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* libglusterfs: remove compound-fop helper functionsAmar Tumballi2019-04-293-177/+3
| | | | | | updates: bz#1693692 Change-Id: If69702990af273be1f38855ba56b3b89fabff167 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* cloudsync/cvlt: Cloudsync plugin for commvault storeAnuradha Talur2019-04-261-0/+1
| | | | | | Change-Id: Icbe53e78e9c4f6699c7a26a806ef4b14b39f5019 updates: bz#1642168 Signed-off-by: Anuradha Talur <atalur@commvault.com>
* logging.c/h: aggressively remove sprintfs()Yaniv Kaul2019-04-252-328/+201
| | | | | | | | | | | | | | | | | | | | | | Try to reduce the number of sprintf() and string copies until we finally log a log line. Specifically, do not sprintf separately the timestr string and do not sprintf/strcpy the appmsgstr separately - just stick it with the header. Hoping I did not leak anything or changed the log line formatting. Also, allocate 4K (GF_LOG_BACKTRACE_SIZE) of memory dynamically for trace output - only if trace was actually requested (previously, it was unconditionally) In addition, some minor code formatting (unrelated to the above). updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: Id2ccc85f9213a2b1c6eaa4a2f58ce043eac1824f
* core: avoid dynamic TLS allocation when possibleXavi Hernandez2019-04-246-431/+105
| | | | | | | | | | | | | | | | | | | Some interdependencies between logging and memory management functions make it impossible to use the logging framework before initializing memory subsystem because they both depend on Thread Local Storage allocated through pthread_key_create() during initialization. This causes a crash when we try to log something very early in the initialization phase. To prevent this, several dynamically allocated TLS structures have been replaced by static TLS reserved at compile time using '__thread' keyword. This also reduces the number of error sources, making initialization simpler. Updates: bz#1193929 Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* core: fix hang issue in __gf_freeSusant Palai2019-04-221-1/+0
| | | | | | | | | | | | | | | Currently GF_ASSERT is done under mem_accounting lock at some places. On a GF_ASSERT failure, gf_msg_callingfn is called which calls gf_malloc internally and it takes the same mem_accounting lock leading to deadlock. This is a temporary fix to avoid any hang issue in master. https://review.gluster.org/#/c/glusterfs/+/22589/ is being worked on in the mean while so that GF_ASSERT can be used under mem_accounting lock. Change-Id: I6d67f23979e7edd2695bdc6aab2997dae4a4060a updates: bz#1700865 Signed-off-by: Susant Palai <spalai@redhat.com>
* core: handle memory accounting correctlyXavi Hernandez2019-04-224-114/+105
| | | | | | | | | | | | | | | | | | | | When a translator stops, memory accounting for that translator is not destroyed (because there could remain memory allocated that references it), but mutexes that coordinate updates of memory accounting were destroyed. This caused incorrect memory accounting and even crashes in debug mode. This patch also fixes some other things: * Reduce the number of atomic operations needed to manage memory accounting. * Correctly account memory when realloc() is used. * Merge two critical sections into one. * Cleaned the code a bit. Change-Id: Id5eaee7338729b9bc52c931815ca3ff1e5a7dcc8 Updates: bz#1659334 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* shd/mux: Fix coverity issues introduced by shd mux patchMohammed Rafi KC2019-04-151-8/+13
| | | | | | | | | | | | | CID 1400475: Null pointer dereferences (FORWARD_NULL) CID 1400474: Null pointer dereferences (FORWARD_NULL) CID 1400471: Code maintainability issues (UNUSED_VALUE) CID 1400470: Null pointer dereferences (FORWARD_NULL) CID 1400469: Memory - illegal accesses (USE_AFTER_FREE) CID 1400467: Code maintainability issues (UNUSED_VALUE) Change-Id: I0ca1c733be335c6e5844f44850f8066626ac40d4 updates: bz#789278 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* core: Log level changes do not effect on running client processMohit Agrawal2019-04-151-0/+1
| | | | | | | | | | | | | | | | | | | Problem: commit c34e4161f3cb6539ec83a9020f3d27eb4759a975 set log-level per xlator during reconfigure only for a brick process not for the client process. Solution: 1) Change per xlator log-level only if brick_mux is enabled.To make sure about brick multiplex introudce a flag brick_mux at ctx->cmd_args. Note: There are two other changes done with this patch 1) Ignore client-log-level option to attach a brick with already running brick if brick_mux is enabled 2) Add a log to print pid of the running process to make easier debugging Change-Id: I39e85de778e150d0685cd9a79425ce8b4783f9c9 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com> Fixes: bz#1696046
* graph.c: remove extra gettimeofday() - reuse the graph dob.Yaniv Kaul2019-04-152-19/+10
| | | | | | | | | | | | | It was written just before fill_void() call. Note that there was a possible overflow if the hostname was too long (unrelated to this patch), but it is now also fixed, as we use a smaller buffer for the hostname. This, in turn, forces us to check if gethostname() failed and add explicitly the terminating null to it. Change-Id: I45fbc0a8e105f1247f3cbf61befac06fabbaea06 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* Replace memdup() with gf_memdup()Vijay Bellur2019-04-124-17/+5
| | | | | | | | | memdup() and gf_memdup() have the same implementation. Removed one API as the presence of both can be confusing. Change-Id: I562130c668457e13e4288e592792872d2e49887e updates: bz#1193929 Signed-off-by: Vijay Bellur <vbellur@redhat.com>
* core: only log seek errors if SEEK_HOLE/SEEK_DATA is availableNiels de Vos2019-04-111-0/+4
| | | | | | | | | | | | | | | | | | | On RHEL-6 there is no support for SEEK_HOLE/SEEK_DATA and this causes the POSIX xlator to return errno=EINVAL. Because of this, the rpc-server xlator will log all 'failed' seek attempts. When applications call seek() often, the brick logs can grow very quickly and fill up the disks. Messages that get logged are like [server-rpc-fops.c:2091:server_seek_cbk] 0-vol01-server: 4947: SEEK-2 (53920aee-062c-4598-aa50-2b4d7821b204), client: worker.example.com-7808-2019/02/08-18:04:57:903430-vol01-client-0-0-0, error-xlator: vol01-posix [Invalid argument] The problem can be reproduced by running a Gluster Server on RHEL-6, with a client running on RHEL-7. The client should execute an application that calls lseek() with SEEK_HOLE/SEEK_DATA. Change-Id: I7b6c16f8e0ba1a183e845cfdb8d5a3f8caeab138 Fixes: bz#1697316 Signed-off-by: Niels de Vos <ndevos@redhat.com>
* libglusterfs: define macros needed for cloudsyncAnuradha Talur2019-04-041-0/+4
| | | | | | Change-Id: Iec5ce7f17fbf899f881a58cd20c4c967e3b71668 fixes: bz#1642168 Signed-off-by: Anuradha Talur <atalur@commvault.com>
* logging: Fix GF_LOG_OCCASSIONALLY APIAtin Mukherjee2019-04-021-1/+1
| | | | | | | | | | | GF_LOG_OCCASSIONALLY doesn't log on the first instance rather at every 42nd iterations which isn't effective as in some cases we might not have the code flow hitting the same log for as many as 42 times and we'd end up suppressing the log. Fixes: bz#1694925 Change-Id: Iee293281d25a652b64df111d59b13de4efce06fa Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
* mgmt/shd: Implement multiplexing in self heal daemonMohammed Rafi KC2019-04-019-3/+508
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Shd daemon is per node, which means they create a graph with all volumes on it. While this is a great for utilizing resources, it is so good in terms of performance and managebility. Because self-heal daemons doesn't have capability to automatically reconfigure their graphs. So each time when any configurations changes happens to the volumes(replicate/disperse), we need to restart shd to bring the changes into the graph. Because of this all on going heal for all other volumes has to be stopped in the middle, and need to restart all over again. Solution: This changes makes shd as a per volume daemon, so that the graph will be generated for each volumes. When we want to start/reconfigure shd for a volume, we first search for an existing shd running on the node, if there is none, we will start a new process. If already a daemon is running for shd, then we will simply detach a graph for a volume and reatach the updated graph for the volume. This won't touch any of the on going operations for any other volumes on the shd daemon. Example of an shd graph when it is per volume graph ----------------------- | debug-iostat | ----------------------- / | \ / | \ --------- --------- ---------- | AFR-1 | | AFR-2 | | AFR-3 | -------- --------- ---------- A running shd daemon with 3 volumes will be like--> graph ----------------------- | debug-iostat | ----------------------- / | \ / | \ ------------ ------------ ------------ | volume-1 | | volume-2 | | volume-3 | ------------ ------------ ------------ Change-Id: Idcb2698be3eeb95beaac47125565c93370afbd99 fixes: bz#1659708 Signed-off-by: Mohammed Rafi KC <rkavunga@redhat.com>
* mem-pool: remove dead code.Yaniv Kaul2019-03-262-81/+0
| | | | | | Change-Id: I3bbda719027b45e1289db2e6a718627141bcbdc8 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* inode: fix unused varsAtin Mukherjee2019-03-221-1/+2
| | | | | | | | | Commit 6d6a3b2 introduced some unused vars. This patch defines them within #ifdef DEBUG Fixes: bz#1580315 Change-Id: I8a332b00c3ffb66689b4b6480c490b9436c17d63 Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
* inode: don't dump the whole table to CLIAmar Tumballi2019-03-201-0/+13
| | | | | | | | | | | dumping the whole inode table detail to screen doesn't solve any purpose. We should be getting only toplevel details on CLI, and then if one wants to debug further, then they need to get to 'statedump' to get full details. Fixes: bz#1580315 Change-Id: Iaf3de94602f9c76832c3c918ffe2ad13c0b0e448 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* cluster-syncop: avoid duplicate unlock of inodelk/entrylkKinglong Mee2019-03-181-0/+6
| | | | | | | | | | | When using ec, there are many messages at brick log as, [inodelk.c:514:__inode_unlock_lock] 0-test-locks: Matching lock not found for unlock 0-9223372036854775807, lo=68e040a84b7f0000 on 0x7f208c006f78 [MSGID: 115053] [server-rpc-fops_v2.c:280:server4_inodelk_cbk] 0-test-server: 2557439: INODELK <gfid:df4e41be-723f-4289-b7af-b4272b3e880c> (df4e41be-723f-4289-b7af-b4272b3e880c), client: CTX_ID:67d4a7f3-605a-4965-89a5-31309d62d1fa-GRAPH_ID:0-PID:1659-HOST:openfs-node2-PC_NAME:test-client-1-RECON_NO:-28, error-xlator: test-locks [Invalid argument] Change-Id: Ib164d29ebb071f620a4ca9679c4345ef7c88512a Updates: bz#1689920 Signed-off-by: Kinglong Mee <mijinlong@open-fs.com>
* glusterfsd: Multiple shd processes are spawned on brick_mux environmentMohit Agrawal2019-03-121-1/+2
| | | | | | | | | | | | | | | | | | | Problem: Multiple shd processes are spawned while starting volumes in the loop on brick_mux environment.glusterd spawn a process based on a pidfile and shd daemon is taking some time to update pid in pidfile due to that glusterd is not able to get shd pid Solution: Commit cd249f4cb783f8d79e79468c455732669e835a4f changed the code to update pidfile in parent for any gluster daemon after getting the status of forking child in parent.To resolve the same correct the condition update pidfile in parent only for glusterd and for rest of the daemon pidfile is updated in child Change-Id: Ifd14797fa949562594a285ec82d58384ad717e81 fixes: bz#1684404 Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
* glusterd: change the op-versionSanju Rakonde2019-03-112-1/+3
| | | | | | | | | | as commit 073444 is backported to release-5.4 branch, op-version for this change should 5.4 instead of 6. fixes: bz#1685120 Change-Id: Id504b9a1446125cea7c6a32117ccc44f28e73aa7 Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
generated by cgit (git 2.34.1) at 2024-04-29 17:20:39 +0000