| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[sh]$ gcc --version
gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
Warnings were of the type below:
xlators/mgmt/glusterd/src/glusterd-store.c:3285:33:
warning: ‘/options’ directive output may be truncated writing 8 bytes into a region of size between 1 and 4096 [-Wformat-truncation=]
snprintf (path, len, "%s/options", conf->workdir);
^~~~~~~~
xlators/mgmt/glusterd/src/glusterd-store.c:1280:39:
warning: ‘/snaps/’ directive output may be truncated writing 7 bytes into a region of size between 1 and 4096 [-Wformat-truncation=]
snprintf (snap_fpath, len, "%s/snaps/%s/%s", priv->workdir,
^~~~~~~
* Also changed some places where there was issues with key size
* Made sure all the 'char buf[SOMESIZE] = {0,};' are changed to 'char buf[SOMESIZE] = "";`
- In the files I changed
* Also edited coding standard to reflect that.
updates: bz#1193929
Change-Id: I04c652624ac63199cea2077e46b3a5def37c3689
Signed-off-by: Amar Tumballi <amarts@redhat.com>
|
|
|
|
|
|
|
|
| |
Fixes CID 1391418
Change-Id: I60ce6cd3b2528369f4dc1be81c0c15a1a806982a
updates: bz#789278
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
| |
Fixes CID 1394647, 1394658
Change-Id: I30cf6e793919a08e0a3fe10622351b8316d7767c
updates: bz#789278
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
| |
While it is a one line fix, it allows a significant unwanted memory
being allocated for defrag structure.
Updates: bz#1193929
Change-Id: Idda70d1d3dc0e7be56c35e872aa6edfaf752290d
Signed-off-by: Amar Tumballi <amarts@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting the refresh flag in inode ctx in shard_rename_src_cbk()
is applicable only when the dst file exists and is sharded and
has a hard link > 1 at the time of rename.
But this piece of code is exercised even when dst doesn't exist.
In this case, the mount crashes because local->int_inodelk.loc.inode
is NULL.
Change-Id: Iaf85a5ee3dff8b01a76e11972f10f2bb9dcbd407
Updates: bz#1611692
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
|
|
|
|
|
|
|
|
|
| |
An error caused skipped files to be counted as
rebalanced files.
Change-Id: I02333f099fb8b73ba953f41a2922021a1e4da7be
fixes: bz#1615474
Signed-off-by: N Balachandran <nbalacha@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In dht_heal_path, the inodes are created & looked up from top to down.
If the path is "a/b/c", then lookup will be done on a, then b and so
on. Here is a rough snippet of the function "dht_heal_path".
<snippet>
if (bname) { ref_count
- loc.inode = create/grep inode 1
- syncop_lookup (loc.inode)
- linked_inode = inode_link (loc.inode) 2
/*clean up current loc*/
- loc_wipe(&loc) 1
/*set up parent and bname for next child */
- loc.parent = inode
- bname = next_child_name
}
out:
- inode_ref (linked_inode) 2
- loc_wipe (&loc) 1
</snippet>
The problem with the above code is if _bname_ is empty ie the chain lookup is
done, then for the next iteration we populate loc.parent anyway. Now that
bname is empty, the loc_wipe is done in the _out_ section as well. Since, the
loc.parent was set to the previous inode, we lose a ref unwantedly. Now a
dht_local_wipe as part of the DHT_STACK_UNWIND takes away the last ref leading
to inode_destroy.
This problenm is observed currently with nfs-ganesha with the nameless lookup.
Post the inode_purge, gfapi does not get the new inode to link and hence, it links
the inode it sent in the lookup fop, which does not have any dht related context
(layout) leading to "invalid argument error" in lookup path done parallely with tar
operation.
test done in the following way:
- create two nfs client connected with two different nfs servers.
- run untar on one client and run lookup continuously on the other.
- Prior to this patch, invalid arguement was seen which is fixed with
the current patch.
Change-Id: Ifb90c178a2f3c16604068c7da8fa562b877f5c61
fixes: bz#1610256
Signed-off-by: Susant Palai <spalai@redhat.com>
|
|
|
|
|
|
|
|
| |
Fixes CID 1325557
Change-Id: I5e33ae19ddf4c44a49a2b3b3dea0c739bc96d3a7
updates: bz#789278
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not needed.
There's a good chance the compiler is smart enough to remove it
anyway, but it can't hurt - I hope.
Compile-tested only!
Change-Id: Id7c054e146ba630227affa591007803f3046416b
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
|
|
|
|
|
|
|
|
| |
s/coverty/coverity/
Change-Id: Iac7c13176162eace4247dd3236373aa76d906380
updates: bz#789278
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is the gcc8 warning:
libcloudsyncs3.c: In function ‘aws_download_s3’:
libcloudsyncs3.c:480:48: error: ‘%s’ directive output may be
truncated writing up to 4095 bytes into a region of size
1015 [-Werror=format-truncation=]
snprintf(buf, sizeof(buf), "https://%s/%s", priv->hostname, resource);
libcloudsyncs3.c:480:9: note: ‘snprintf’ output 10 or more bytes
(assuming 4105) into a destination of size 1024
snprintf(buf, sizeof(buf), "https://%s/%s", priv->hostname, resource);
Memleak:
It fixes a memleak as well where sign_req in fn: aws_form_request was
not freed. Adjusted the calloc size for sign_req as well to match with
the demand.
Test:
Have tested the local cloudsync regression test to validate the changes.
Smoke validation will be sufficient for the gcc8 warning fixes.
Fixes: bz#1609126
Change-Id: I1c537b30168f2e0b54862344a951843e86b0b488
Signed-off-by: Susant Palai <spalai@redhat.com>
|
|
|
|
|
|
| |
updates: #302
Change-Id: I9c1b9c9751c21866b074ac5d3ef15a58ae7aa707
Signed-off-by: Prashanth Pai <ppai@redhat.com>
|
|
|
|
|
|
| |
Change-Id: I37a6e0efda430b70d03dd431c35bef23b3d16361
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During friend handshake if the glusterd receives more than one friend
updates, it might very well become possible that two threads would end
up working on two different volinfo references and glusterd might end up
updating the store with a old volinfo reference. While debugging
glusterd crash from validating-server-quorum.t test file from the
line-coverage regression the same was observed.
Solution is to run glusterd_compare_friend_data under a mutex.
Test:
As the crash was more visible in the line-coverage run (given lcov does
some instrumentation and exposes the races), 6 manual lcov runs were
triggered starting from https://build.gluster.org/job/line-coverage/443
to https://build.gluster.org/job/line-coverage/449/ and no crash was
observed from validating-server-quorum.t
Change-Id: I86fce473a76fd24742d51bf17a685d28b90a8941
Fixes: bz#1603063
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: After reboot a node brick is not coming up because
fsid comparison is failed before start a brick
Solution: Instead of comparing fsid compare volume_id to
resolve the same because fsid is changed after
reboot a node but volume_id persist as a xattr
on brick_root path at the time of creating a volume.
Change-Id: Ic289aab1b4ebfd83bbcae8438fee26ae61a0fff4
fixes: bz#1612418
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While gf_attach () utility can help in detaching a brick instance from
the brick process which the kill_brick () function in tests/volume.rc
uses it has a caveat which is as follows:
1. It doesn't ensure the respective brick is marked as stopped which
glusterd does from glusterd_brick_stop
2. Sometimes if kill_brick () is executed just after a brick stack is
up, the mgmt_rpc_notify () can take some time before marking
priv->connected to 1 and before it if kill_brick () is executed, brick
will fail to initiate the pmap_signout which would inturn cleans up the
pidfile.
To avoid such possibilities, a more stricter check on if a brick is
running or not in brick multiplexing has been brought in now where it
not only checks for its pid's existance but checks if the respective
process has the brick instance associated with it before checking for
brick's status.
Change-Id: I98b92df949076663b9686add7aab4ec2f24ad5ab
Fixes: bz#1595320
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once invalidated, make sure that only ops incident after invalidation
update the cache. This makes sure that ops before invalidation don't
repopulate cache with stale data. This patch also uses an internal
counter instead of frame->root->unique for keeping track of
generations.
Change-Id: I6b38b141985283bd54b287775f3ec67b88bf6cb8
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
| |
Instead of not defining the 'seek' fop when it's not supported on the
compilation platform, we simply return EINVAL when it's used.
Fixes: bz#1611834
Change-Id: I253666d8910c5e2fffa3a3ba37085e5c1c058a8e
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modified while in cache"
This reverts commit 7131de81f72dda0ef685ed60d0887c6e14289b8c.
With the latest master, I created a single brick volume and some files
inside it.
[root@rhgs313-6 ~]# umount -f /mnt/fuse1; mount -t glusterfs -s
192.168.122.6:/thunder /mnt/fuse1; ls -l /mnt/fuse1/; echo "Trying
again"; ls -l /mnt/fuse1
umount: /mnt/fuse1: not mounted
total 0
----------. 0 root root 0 Jan 1 1970 file-1
----------. 0 root root 0 Jan 1 1970 file-2
----------. 0 root root 0 Jan 1 1970 file-3
----------. 0 root root 0 Jan 1 1970 file-4
----------. 0 root root 0 Jan 1 1970 file-5
d---------. 0 root root 0 Jan 1 1970 subdir
Trying again
total 3
-rw-r--r--. 1 root root 33 Aug 3 14:06 file-1
-rw-r--r--. 1 root root 33 Aug 3 14:06 file-2
-rw-r--r--. 1 root root 33 Aug 3 14:06 file-3
-rw-r--r--. 1 root root 33 Aug 3 14:06 file-4
-rw-r--r--. 1 root root 33 Aug 3 14:06 file-5
d---------. 0 root root 0 Jan 1 1970 subdir
[root@rhgs313-6 ~]#
Conversation can be followed on gluster-devel on thread with subj:
tests/bugs/distribute/bug-1122443.t - spurious failure. git-bisected
pointed this patch as culprit.
Change-Id: I1eb46f6c196f44fde8ce991840a0e724e6f50862
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1390050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue 1:
========
open all pending fds before resuming rename and unlink
currently ob uses fd_lookup to find out the opened-behind. But,
fd_lookup gives the recent fd opened on the inode, but the oldest
fd(s) (there can be multiple fds opened-behind when the very first
opens on an inode are issued in parallel) are the candidates for fds
with pending opens on backend. So, this patch explictily tracks the
opened-behind fds on an inode and opens them before resuming rename or
unlink.
similar code changes are also done for setattr and setxattr to make
sure pending opens are complete before permission change.
This patch also adds a check for an open-in-progress to
ob_get_wind_fd. If there is already an open-in-progress,
ob_get_wind_fd won't return an anonymous fd as a result. This is done
to make sure that rename/unlink/setattr/setxattr don't race with an
operation like readv/fstat on an anonymous fd already in progress.
Issue 2:
========
once renamed/unlinked, don't open-behind any future opens on the same
inode.
Issue 3:
========
Don't use anonymous fds by default. Note that rename/unlink can race
with a read/fd on anonymous fds and these operations can fail with
ESTALE. So, for better consistency in default mode, don't use
anonymous fds. If performance is needed with tradeoff of consistency,
one can switch on the option "use-anonymous-fd"
Change-Id: Iaf130db71ce61ac37269f422e348a45f6ae6e82c
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gluster_shared_storage bricks
Problem: In a brick multiplexing environment, Bricks of a normal volume
created by user are getting attached to the bricks of a volume
"gluster_shared_storage" which is created by enabling the
enable-shared-storage option. Mounting gluster_shared_storage
has strict authentication checks. when we attach bricks of a normal
volume to bricks of gluster_shared_storage, mounting the normal
volume created by user will fail due to strict authentication checks.
Solution: We should not attach bricks of a normal volume to brick
process of gluster_shared_storage volume and vice versa.
fixes: bz#1610726
Change-Id: If1b5a2a02675789a2915ba480fb48c145449163d
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
anonymous fds interfere with working of read-ahead as read-ahead won't
be able to store its cache in fd. Also, as seen in bz 1455872,
anonymous fds also affect performance of large file sequential reads
as the cost of opening fd for each read on brick stack is
significant. So, have a proper fd which enables read-ahead to store
its cache and brick stack to reuse the fd during reads.
With this change test
tests/bugs/snapshot/bug-1167580-set-proper-uid-and-gid-during-nfs-access.t
fails consistently. The failure can also be seen with open-behind
off. bz 1611532 has been filed to track the issue with test. Thanks to
Rafi <rkavunga@redhat.com> for assistance provided in debugging test
failure.
Change-Id: Ifa52d8ff017f115e83247f3396b9d27f0295ce3f
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Fixes: bz#1455872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalidation
Invalidations are triggered mainly by two codepaths - upcall and
write-behind unwinding a cached write with zeroed out stat. For the
case of upcall, following race can happen:
* stat s1 is fetched from brick
* invalidation is detected on brick
* invalidation is propagated to md-cache and cache is invalidated
* s1 updates md-cache with a stale state
For the case of write-behind, imagine following sequence of operations,
* A stat s1 was issued from application thread t1 when size of file
was s1
* stat s1 completes on brick stack, but yet to reach md-cache
* A write w1 from application thread t2 extends file to size s2 is
cached in write-behind and response is unwound with zeroed out stat
* md-cache while handling write-cbk, invalidates cache
* md-cache receives response for s1, updates cache with stale stat
with size of s1 overwriting invalidation state
Fix is to remember when s1 was incident on md-cache and update cache
with results of s1 only if the it was incident after invalidation of
cache.
This patch identified some bugs in regression tests which is tracked
in https://bugzilla.redhat.com/show_bug.cgi?id=1608158. As a stop gap
measure I am marking following tests as bad
basic/afr/split-brain-resolution.t
bugs/bug-1368312.t
bugs/replicate/bug-1238398-split-brain-resolution.t
bugs/replicate/bug-1417522-block-split-brain-resolution.t
bugs/replicate/bug-1438255-do-not-mark-self-accusing-xattrs.t
Change-Id: Ia4bb9dd36494944e2d91e9e71a79b5a3974a8c77
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
|
|
| |
rename response contains a postbuf stat of src-inode. Since md-cache
caches stat in rename codepath too, we've to make sure stat accounts
any cached writes in write-behind. So, we make sure rename is resumed
only after any cached writes are committed to backend.
Change-Id: Ic9f2adf8edd0b58ebaf661f3a8d0ca086bc63111
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current invalidation of stats in wb_readdirp_cbk is prone to races. As
the deleted comment explains,
<snip>
We cannot guarantee integrity of entry->d_stat as there are cached
writes. The stat is most likely stale as it doesn't account the cached
writes. However, checking for non-empty liability list here is not a
fool-proof solution as there can be races like,
1. readdirp is successful on posix
2. sync of cached write is successful on posix
3. write-behind received sync response and removed the request from
liability queue
4. readdirp response is processed at write-behind.
In the above scenario, stat for the file is sent back in readdirp
response but it is stale.
</snip>
Change-Id: I6ce170985cc6ce3df2382ec038dd5415beefded5
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
while in cache
PROBLEM:
Entries that are readdirp'd ahead can undergo modification in terms
of writes, truncates which could modify their iatts. When a readdir
is finally wound at offset corresponding to these entries, the iatts
that are returned to the application come from readdir-ahead's cache,
which are stale by now. This problem gets further aggravated when caching
translators/modules cache and continue to serve this stale information.
FIX:
Whenever a dentry undergoes modification, in the cbk of the modification fop,
a "dirty" flag (default 0) is set in its inode ctx. When it's time for
readdir-ahead to serve these entries, it will read the inode ctx and check
if the entry is "dirty", and if it is, set the entry's attrs to all zeroes,
as an indicator to fuse, md-cache etc not to cache these attributes.
Also there is one tiny race between the entry creation and a readdirp on its
parent dir, which could cause the inode-ctx setting and inode ctx reading to
happen on two different inode objects. To prevent this, fuse-bridge is made to
drop entries for which dentry->inode is not the same as linked inode,
in readdirp cbk.
Change-Id: If7396507632b5268442ca580473d5155fee9cbef
BUG: 1390050
Updates: bz#1390050
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newer FreeBSD versions (noticed with 10.3-RELEASE) provide a event.h
file that on occasion gets included instead of the libglusterfs file.
When this happens, 'struct event_pool' will not be defined and building
will fail with errors like:
autoscale-threads.c:18:55: error: incomplete definition of type 'struct event_pool'
int thread_count = pool->eventthreadcount;
~~~~^
autoscale-threads.c:17:16: note: forward declaration of 'struct event_pool'
struct event_pool *pool = ctx->event_pool;
^
This problem is caused by 'pkg-config --cflags uuid' that adds
/usr/local/include to the GF_CPPFLAGS. The use of libuuid is preferred
so that the contrib/uuid/ directory can be removed.
By renaming event.h to gf-event.h there is no conflict between the
different event.h files anymore and compiling on FreeBSD works without
issues.
Change-Id: Ie69f6b8a4f8f8e9630d39a86693eb74674f0f763
Updates: bz#1607319
Signed-off-by: Niels de Vos <ndevos@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
This patch moves stack based PATH_MAX allocations for tmpfile
names, to heap allocated names instead. Reducing the impact on
stack space used and accruing benefits thereof.
Change-Id: I646d9cb091018de6768b3523902788fa2ba14d96
Updates: bz#1193929
Signed-off-by: ShyamsundarR <srangana@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: In brick mux scenario sometime glusterd is not able
to start/attach a brick and gluster v status shows
brick is already running
Solution:
1) To make sure brick is running check brick_path in
/proc/<pid>/fd , if a brick is consumed by the brick
process it means brick stack is come up otherwise not
2) Before start/attach a brick check if a brick is mounted
or not
3) At the time of printing volume status check brick is
consumed by any brick process
Test: To test the same followed procedure
1) Setup brick mux environment on a vm
2) Put a breaking point in gdb in function posix_health_check_thread_proc
at the time of notify GF_EVENT_CHILD_DOWN event
3) unmount anyone brick path forcefully
4) check gluster v status it will show N/A for the brick
5) Try to start volume with force option, glusterd throw
message "No device available for mount brick"
6) Mount the brick_root path
7) Try to start volume with force option
8) down brick is started successfully
Change-Id: I91898dad21d082ebddd12aa0d1f7f0ed012bdf69
fixes: bz#1595320
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Option list for volume_options in sdfs was not NULL
terminated. This resulted in a crash when running in
lcov based builds.
This is rectified by this patch.
fixes: bz#1608566
Change-Id: I5d8730f1ae963ed6adf21d970e4921c5d5d92f62
Signed-off-by: ShyamsundarR <srangana@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes coverity issues 102, 103, 112 and 119 from [1]
[1] https://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-23-5fa004f3/html/
Updates: bz#789278
Change-Id: I99762eb0bcbd974a5250434777db63520f2ce2e6
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will fix coverity issue 74 from [1].
we are updating ret value line number 5011, and
immediately checking whether ret is having non
zero value at line number 5013.If ret is 0, then
only we continue to execute and we can reach line
number 5036. By the time we reach 5036, ret value
is always 0. So this block of code is redundant
here and removing it.
[1] https://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-23-5fa004f3/html/
Updates: bz#789278
Change-Id: Ia6e8ba2936e350f0d29a9151ab786622f5e750db
Signed-off-by: Oshank Kumar <okumar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently this lru limit is hard-coded to 16384. This patch makes it
configurable to make it easier to hit the lru limit and enable testing
of different cases that arise when the limit is reached.
The option is features.shard-lru-limit. It is by design allowed to
be configured only in init() but not in reconfigure(). This is to avoid
all the complexity associated with eviction of least recently used shards
when the list is shrunk.
Change-Id: Ifdcc2099f634314fafe8444e2d676e192e89e295
updates: bz#1605056
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
posix_set_parent_ctime() unconditionally logs an error if consistent
time attributes is not enabled. This log does not add any value, prints
an incorrect errno & floods the log file.
Hence nuking this log message in this patch.
Change-Id: I82a78f2f8ce5ab518f8cdf6d9086a97049712f75
fixes: bz#1607049
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem : In 'glusterd_verify_slave' while tokenizing error message
we call 'strtok_r' and store return value in 'tmp' which
can be NULL. We are passing this 'tmp' as 1st argument to
'strcmp' which will lead to segmentation fault.
Solution : before calling 'strcmp' we should NULL check 'tmp'.
Change-Id: Ifd3864b904afe6cd09d9e5a4b55c6d0578e22b9d
fixes: bz#1602121
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting in Fedora 26 which has gcc-7.1.x, -Wformat-trunction is enabled
with -Wformat, resulting in a flood of new warnings. This many warnings
is a concern because it makes it hard(er) to see other warnings that
should be addressed.
An example is at
https://kojipkgs.fedoraproject.org//packages/glusterfs/3.12.0/1.fc28/data/logs/x86_64/build.log
For more info see https://review.gluster.org/#/c/18267/
I can't find much (or good) documentation on the heuristics the
compiler uses for this warning. In the case of printing integer types
it appears it looks at the available space in the destination and the
range of values for the variable and/or its type.
To address the specific question about why 0x3ff versus 0xfff to mask
the value, either would suffice to hint to the compiler that the
printed value will fit in three characters. But the loop is from
0...1023 (or 0...0x3ff if you prefer) so I chose that as a more
"accurate" mask to use as it exactly matches the range of values of
the loop.
Fixes: bz#1492847
Change-Id: I6e309ba42159841131d8241bfc0566ef09e00aa9
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
quota enable as volume set needs a new option to keep track of it.
Bugzilla ID:1600812
Change-Id: Ib8d770936bafe859f80e717409bd861760090e59
fixes: bz#1600812
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
|
|
| |
See https://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-13-1718f9c6/html/1/6glusterd-quota.c.html#error
Only compile tested!
Change-Id: Ief42f9fcdb02ad001bd39c4a6e27e7fa86fd2496
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throwaway read-ahead cache in fstat only if force-atime-update is
set. Note that fstat flushes read-ahead cache only for atime
consistency. However if atime consistency is needed user is required
to set force-atime-update which updates atime on backend fs even
though application reads are served from read-ahead cache. So, if user
has not set force-atime-update, atime won't be accurate and there is
no point in flushing read-ahead cache in fstats. mounts
requiring atime consistency have to mandatorily set
force-atime-update.
Also note that normally kernel interspers reads with fstat. So,
read-ahead is not effective as fstats flush read-ahead-cache. Instead
it regresses performance due to wasted network reads. It is
recommended to turn off read-ahead if applications require atime
consistency.
This patch is aimed at applications which don't require atime
consistency. Without atime consistency required, read-ahead cache is
effective and increases performance of sequential reads.
Change-Id: I122bbc410cee96661823f9c4b934383495c18446
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Fixes: bz#1601166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ 1564071 complains of directories with missing gfid symlinks and
corresponding "Found stale gfid handle" messages in the logs. Hence
add a check to see if the symlink points to an actual directory before
removing it.
Note: Removing stale symlinks was added via commit
3e9a9c029fac359477fb26d9cc7803749ba038b2
Change-Id: I5d91fab8e5f3a621a9ecad4a1f9c898a3c2d346a
Updates: bz#1564071
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AFR takes inodelks when setting attrs. The loc->gfid
and loc->inode->gfid were both null when dht_dir_attr_heal
was called during a fresh lookup of an existing directory.
As the gfid is null, client_pre_inodelk asserts in the gfid
check.
We now set the loc->gfid before calling dht_dir_attr_heal.
Change-Id: I457f5a73fd301d97a03ca032587e73d4803298ac
fixes: bz#1602866
Signed-off-by: N Balachandran <nbalacha@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
In a disk full scenario, we take a failure path in afr_transaction_perform_fop()
and go to unlock phase. But we change the lk-owner before that, causing unlock
to fail. When mount issues another fop that takes locks on that file, it hangs.
Fix:
Change lk-owner only when we are about to perform the fop phase.
Also fix the same issue for arbiters when afr_txn_arbitrate_fop() fails the fop.
Also removed the DISK_SPACE_CHECK_AND_GOTO in posix_xattrop. Otherwise truncate
to zero will fail pre-op phase with ENOSPC when the user is actually trying to
freee up space.
Change-Id: Ic4c8a596b4cdf4a7fc189bf00b561113cf114353
fixes: bz#1602236
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: gluster get-state command is leaking the memory when
geo-replication session is configured.
Cause: In glusterd_print_gsync_status(), we are trying to get
reference to the keys of gsync_dict. The references to keys of
gsync_dict are stored status_vols[i]. status_vols[i] are
allocated with a memory of size of gf_gsync_status_t.
Solution: Need not to use a array of pointers(status_vals), using
a pointer to hold the reference to a key of gsync_dict is sufficient.
Followed the below steps for testing:
1. Configured geo-rep session
2. Ran gluster get-state command for 1000 times.
Without this patch, glusterd's memory was increasing significantly
(around 22000KB per 1000 times), with this patch it reduced (1500KB
per 1000 times)
fixes: bz#1601423
Change-Id: I361f5525d71f821bb345419ccfdc20ca288ca292
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
The last using of the subvol argument has been removed at 4e1ec35ef4f7
("core: fill 'ia_ino' from 'ia_gfid' in 'storage/posix' ......")
7 years ago (2011-06-16).
Change-Id: I9788d79e2e40cc153cf2960e28c7c1c1033dc8f7
fixes: bz#1601683
Signed-off-by: Kinglong Mee <mijinlong@open-fs.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use dict_del instead of GF_REMOVE_INTERNAL_XATTR.
For problem and fix related information see here -
https://review.gluster.org/20450.
This patch have some modification as requested by reviewers on already
merged patch : https://review.gluster.org/20450.
Change-Id: I50c263e3411354bb9c1e028b64b9ebfd755dfe37
fixes: bz#1597563
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no need to format the time, unless ret is true.
I don't think there's a reason to allocate memory for
those struct and char array unless we are formatting
either (But I'm not sure what the code convention is - are we
ok with 'local' variable declarations?)
Only compile-tested.
Change-Id: I9feb09871943764bd76bdfc9ac6ca506f329aac1
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
|
|
|
|
|
|
|
|
|
| |
The same variable 'len' was used both in the macros and the functions.
(Introduced as part of commit 6dc5dfef819cad69d6d4b4c1c305efa74236ad84 ?)
Change-Id: If434999d6470067f8a1e501c8e132561e8cd81ef
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
If an entry creation transaction fails on quprum number of bricks
it might end up setting the pending changelogs on the file itself
on the brick where it got created. But the parent does not have
any entry pending marker set. This will lead to the entry not
getting healed by the self heal daemon automatically.
Fix:
For entry transactions mark dirty on the parent if it fails on
quorum number of bricks, so that the heal can do conservative
merge and entry gets healed by shd.
Change-Id: I56448932dd409b3ddb095e2ae32e037b6157a607
fixes: bz#1586020
Signed-off-by: karthik-us <ksubrahm@redhat.com>
|