lookup-optimize doesn't provide any benefit for virtualized environments and gluster-block workloads, but it's known to cause corruption in some cases when sharding is also enabled and the volume is expanded or shrunk. For this reason, we disable lookup-optimize by default on those environments. Fixes: #2253 Change-Id: I25861aa50b335556a995a9c33318dd3afb41bf71 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
Issue: Mounting shared storage volume was failing in ipv6 env if the hostnames were FQDNs. The brickname for the volume was being cut off, as a result, volume creation was failing Change-Id: Ib38993724c709b35b603f9ac666630c50c932c3e Updates: #1406 Signed-off-by: nik-redhat <nladha@redhat.com>
Comments and idea proposed by: Xavi Hernandez(jahernan@redhat.com): On production systems sometimes we see a log message saying that an assertion has failed. But it's hard to track why it failed without additional information (on debug builds, a GF_ASSERT() generates a core dump and kills the process, so it can be used to debug the issue, but many times we are only able to reproduce assertion failures on production systems, where GF_ASSERT() only logs a message and continues). In other cases we may have a core dump caused by a bug, but the core dump doesn't necessarily happen when the bug has happened. Sometimes the crash happens so much later that the causes that triggered the bug are lost. In these cases we can add more assertions to the places that touch the potential candidates to cause the bug, but the only thing we'll get is a log message, which may not be enough. One solution would be to always generate a core dump in case of assertion failure, but this was already discussed and it was decided that it was too drastic. If a core dump was really needed, a new macro was created to do so: GF_ABORT(), but GF_ASSERT() would continue to not kill the process on production systems. I'm proposing to modify GF_ASSERT() on production builds so that it conditionally triggers a signal when a debugger is attached. When this happens, the debugger will generate a core dump and continue the process as if nothing had happened. If there's no debugger attached, GF_ASSERT() will behave as always. The idea I have is to use SIGCONT to do that. This signal is harmless, so we can unmask it (we currently mask all unneeded signals) and raise it inside a GF_ASSERT() when some global variable is set to true. To produce the core dump, run the script under extras/debug/gfcore.py on other terminal. gdb breaks and produces coredump when GF_ASSERT is hit. The script is copied from #1810 which is written by Xavi Hernandez(jahernan@redhat.com) Fixes: #1810 Change-Id: I6566ca2cae15501d8835c36f56be4c6950cb2a53 Signed-off-by: Vinayakswami Hariharmath <vharihar@redhat.com>
better whitespace in regex This has worked for years, but somehow no longer works on rhel8 Updates: #1000 Change-Id: I2c1a3537573d125608334772ba1a263c55407dd4 Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
* extras/rebalance: Script to perform directory rebalance How should the script be executed? $ /path/to/directory-rebalance.py <dir-to-rebalance> will do rebalance just for that directory. The script assumes that fix-layout operation is completed for all the directories present inside the <dir-to-rebalance> How does it work? For the given directory path that needs to be rebalanced, full crawl is performed and the files that need to be healed and the size of each file is first written to the index. Once building the index is completed, the index is read and for each file the script executes equivalent of setfattr -n trusted.distribute.migrate-data -v 1 <path/to/file> Why does the script take two passes? Printing a sensible ETA has been a primary goal of the script. Without knowing the approximate size that will be rebalanced, it is difficult to find ETA. Hence the script does one pass to find files, sizes which it writes to the index file and then the next pass is done on the index file. It takes a minute or two for the ETA to converge but in our testing it has been giving a reasonable ETA What versions does the script support? For the script to work correctly, dht should handle "trusted.distribute.migrate-data" setxattr correctly. fixes: #1654 Change-Id: Ie5070127bd45f1a1b9cd18ed029e364420c971c1 Signed-off-by: Pranith Kumar K <pranith.karampuri@phonepe.com>
Issue: While decoding the byte characters the quota_fsck script stumbled across a corner case wherein the file names given by the getfattr dump will cause the decoding to UTF-8 to fail with UnicodeDecodeError. Code Change: On looking through the quota_fsck.py script, it seems like the file path is actually not needed when decoding for the xattr parsing, hence the code change reflects that. Also, removed a comparison which previously existed to skip the file names as that won't be required now. Fixes: #1487 Change-Id: I8a13ab07be6c9cfafae996f17764fbb4a285bd8c Signed-off-by: srijan-sivakumar <ssivakum@redhat.com>
The patch https://review.gluster.org/#/c/glusterfs/+/24934/, changes mount point of gluster_shared_storage from /var/run to /run to address the issue of symlink at mount path in fstab. NOTE: mount point /var/run is symlink to /run The required changes with respect to gluster_shared_storage mount path are introduced with this patch in nfs-ganesha. Fixes: #1475 Change-Id: I9c7677a053e1291f71476d47ba6fa2e729f59625 Signed-off-by: Shwetha K Acharya <sacharya@redhat.com>
The patch https://review.gluster.org/#/c/glusterfs/+/24934/, changes mount point of gluster_shared_storage from /var/run to /run to address the issue of symlink at mount path in fstab. NOTE: mount point /var/run is symlink to /run The required changes with respect to gluster_shared_storage mount path are introduced with this patch in snap_scheduler. Fixes: #1476 Change-Id: I9ce88c2f624c6aa5982de04edfee2d0a9f160d62 Signed-off-by: Shwetha K Acharya <sacharya@redhat.com>
Issue: On reboot, all the mounts get wiped out.
Only the mounts mentioned in /etc/fstab automatically gets mounted
during boot/reboot.
But /etc/fstab complains on not getting a canonical path
(it gets path containing a symlink)
This is because the gluster_shared_storage, is mounted to
/var/run which is symlink to /run. This is a general practice
followed by most operating systems.
[root@ ~]# ls -lsah /var/run
0 lrwxrwxrwx. 1 root root 6 Jul 22 19:39 /var/run -> ../run
Fix: Mount gluster_shared_storage on /run.
(Also It is seen that /var/run is mostly
used by old or legacy systems, thus it is a good practice to
update /var/run to /run)
fixes: #1459
Change-Id: I8c16653be8cd746c84f01abf0eea19284fb97c77
Signed-off-by: Shwetha K Acharya <sacharya@redhat.com>
Extend '-enable-valgrind' to '--enable=valgrind[=memcheck,drd]' to enable Memcheck or DRD Valgrind tool, respectively. Change-Id: I80d13d72ba9756e0cbcdbeb6766b5c98e3e8c002 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Updates: #1002