| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Null character string is a valid xattr value in file system. But for
those xattrs processed by md-cache, it does not update its entries if
value is null('\0'). This results in ENODATA when those xattrs are
queried afterwards via getxattr() causing failures in basic operations
like create, copy etc in a specially configured Samba setup for Mac OS
clients.
On the other side snapview-server is internally setting empty string("")
as value for xattrs received as part of listxattr() and are not intended
to be cached. Therefore we try to maintain that behaviour using an
additional dictionary key to prevent updation of entries in getxattr()
and fgetxattr() callbacks in md-cache.
Credits: Poornima G <pgurusid@redhat.com>
Change-Id: I7859cbad0a06ca6d788420c2a495e658699c6ff7
Fixes: bz#1743782
Signed-off-by: Anoop C S <anoopcs@redhat.com>
(cherry picked from commit b4b683736367d93daad08a5ee6ca95778c07c5a4)
|
|
|
|
|
|
|
| |
Fixes: bz#1741044
Change-Id: I29e338bac62104233a6f80212df8d0fb016affda
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
(cherry picked from commit 8e9c53ebf16705b9a1db2fc486dc24a5cb244ddd)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: sometime ./tests/bugs/glusterd/bug-1595320.t is failing is
failing at the time of checking brick_process after sending
a kill signal to brick process
Solution: Wait sometime after just sending a kill signal to brick
process to make sure brick process is stopped
> Change-Id: Iee9e91284618abfc62a550d47e4f9117785def58
> Fixes: bz#1743200
> Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
> (cherry picked from commit 8f1620ad7f5d3d040fee55c5f873349800e2268d)
Change-Id: Iee9e91284618abfc62a550d47e4f9117785def58
Fixes: bz#1745421
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Some of the .t are failed due to bind is throwing
an error EADDRINUSE
Solution: After killing all gluster processes .t is trying
to start glusterd but somehow if kernel has not cleaned
up resources(socket) then glusterd startup is failed due to
bind system call failure.To avoid the issue retries to call
bind 10 times to execute system call succesfully
> Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
> Fixes: bz#1743020
> Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
> (cherry picked from commit c370c70f77079339e2cfb7f284f3a2fb13fd2f97)
Change-Id: Ia5fd6b788f7b211c1508c1b7304fc08a32266629
Fixes: bz#1743219
Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two reasons:
* ping responses from glusterd may not be relevant for Halo
replication. Instead, it might be interested in only knowing whether
the brick itself is responsive.
* When a brick is killed, propagating GF_EVENT_CHILD_PING of ping
response from glusterd results in GF_EVENT_DISCONNECT spuriously
propagated to parent xlators. These DISCONNECT events are from the
connections client establishes with glusterd as part of its
reconnect logic. Without GF_EVENT_CHILD_PING, the last event
propagated to parent xlators would be the first DISCONNECT event
from brick and hence subsequent DISCONNECTS to glusterd are not
propagated as protocol/client prevents same event being propagated
to parent xlators consecutively. propagating GF_EVENT_CHILD_PING for
ping responses from glusterd would change the last_sent_event to
GF_EVENT_CHILD_PING and hence protocol/client cannot prevent
subsequent DISCONNECT events
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Fixes: bz#1739335
Change-Id: I50276680c52f05ca9e12149a3094923622d6eaef
(cherry picked from commit 5d66eafec581fb3209af74595784be8854ca40a4)
|
|
|
|
|
|
|
| |
Fixes: bz#1737311
Change-Id: I1f54bc9b04ee05c8ab802d92c1471cbfb1aa92a8
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the nfs EXCLUSIVE mode create may sets a later time
to mtime (at verifier), it should not set to ctime for
storage.ctime does not allowed set ctime to a earlier time.
/* Earlier, mdata was updated only if the existing time is less
* than the time to be updated. This would fail the scenarios
* where mtime can be set to any time using the syscall. Hence
* just updating without comparison. But the ctime is not
* allowed to changed to older date.
*/
According to kernel's setattr, always set ctime at setattr,
and doesnot set ctime from mtime at storage.ctime.
Backport of:
> Patch: https://review.gluster.org/23154
> Change-Id: I5cfde6cb7f8939da9617506e3dc80bd840e0d749
> BUG: 1737288
> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Change-Id: I5cfde6cb7f8939da9617506e3dc80bd840e0d749
fixes: bz#1737746
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Ctime heals the ctime xattr ("trusted.glusterfs.mdata") in lookup
if it's not present. In a multi client scenario, there is a race
which results in updating the ctime xattr to older value.
e.g. Let c1 and c2 be two clients and file1 be the file which
doesn't have the ctime xattr. Let the ctime of file1 be t1.
(from backend, ctime heals time attributes from backend when not present).
Now following operations are done on mount
c1 -> ls -l /mnt/file1 | c2 -> ls -l /mnt/file1;echo "append" >> /mnt/file1;
The race is that the both c1 and c2 didn't fetch the ctime xattr in lookup,
so both of them tries to heal ctime to time 't1'. If c2 wins the race and
appends the file before c1 heals it, it sets the time to 't1' and updates
it to 't2' (because of append). Now c1 proceeds to heal and sets it to 't1'
which is incorrect.
Solution:
Compare the times during heal and only update the larger time. This is the
general approach used in ctime feature but got missed with healing legacy
files.
Backport of:
> Patch: https://review.gluster.org/23131
> BUG: 1734299
> Change-Id: I930bda192c64c3d49d0aed431ce23d3bc57e51b7
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
fixes: bz#1737745
Change-Id: I930bda192c64c3d49d0aed431ce23d3bc57e51b7
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even the use builtin 'type' command as in patch [1]
causes issues if argument in question is not part of PATH
environment variable for that user. This patch fixes the
same by doing source /etc/profile. This was already being
used in another part of script.
[1] https://review.gluster.org/23089
Backport of:
> Patch: https://review.gluster.org/23136/
> Change-Id: Iceb78835967ec6a4350983eec9af28398410c002
> BUG: 1734738
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 84f7794547522463841068063b22fd3a8d8fca2b)
Change-Id: Iceb78835967ec6a4350983eec9af28398410c002
fixes: bz#1737712
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
When frame->local is not null FRAME_DESTROY calls mem_put on it.
Since the stub is already destroyed in call_resume(), it leads
to crash
Fix:
Set frame->local to NULL before calling call_resume()
Backport of:
> Patch: https://review.gluster.org/23091
> BUG: 1593542
> Change-Id: I0f8adf406f4cefdb89d7624ba7a9d9c2eedfb1de
> Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
fixes: bz#1733885
Change-Id: I0f8adf406f4cefdb89d7624ba7a9d9c2eedfb1de
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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#1733885
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch [1] added validation in gverify.sh to check if the gluster
binary exists on slave by executing gluster directly on slave. But for
non-root users, even though gluster binary is present, path is not
found when executed via ssh. Hence validate the gluster binary using
bash builtin 'type' command.
[1] https://review.gluster.org/19224
Backport of:
> Patch: https://review.gluster.org/23089/
> Change-Id: I93ca62c0c5b1e16263e586ddbbca8407d60ca126
> BUG: 1731920
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 2aa731a259ea457c07494e3c3edf6d5f7c02fe77)
Change-Id: I93ca62c0c5b1e16263e586ddbbca8407d60ca126
fixes: bz#1733880
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in bug1733166, there could be potential deadlock
while processing upcalls depending on how each xlator choose
to act on it. The right way of fixing such issues
is to change rpc callback communication process.
- https://github.com/gluster/glusterfs/issues/697
Till then, making changes in gfapi layer to avoid any I/O
processing.
This is backport of below mainline patch
> https://review.gluster.org/#/c/glusterfs/+/23108/
> bz#1733166
Change-Id: I2079e95339e5d761d5060707f4555cfacab95c83
fixes: bz#1736341
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
|
|
|
|
|
|
|
|
|
| |
The current list of snapshots from priv->dirents is obtained outside
the lock.
Change-Id: I8876ec0a38308da5db058397382fbc82cc7ac177
Fixes: bz#1731509
(cherry picked from commit 8e795617fd6f5193d0d52a336059ce1a28108c0e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a bug in the revalidate code path that wiped out
directory permissions if no mds subvol was found.
Backport of:
> Change-Id: I8b4239ffee7001493c59d4032a2d3062586ea115
> fixes: bz#1716830
> Signed-off-by: N Balachandran <nbalacha@redhat.com>
Change-Id: I8b4239ffee7001493c59d4032a2d3062586ea115
fixes: bz#1716848
Signed-off-by: N Balachandran <nbalacha@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to send the commit req to peers in case of geo-rep
operations even though it is a no volname operation. In commit
phase peers try to set the txn_opinfo which will fail because
it is a no volname operation where we don't require a commit
phase. We mark skip_locking as true for no volname operations,
but we have to give an exception to geo-rep operations, so that
they can set txn_opinfo in commit phase.
Please refer to detailed RCA at the bug: 1730545
fixes: bz#1730545
Cherrypicked from https://review.gluster.org/#/c/glusterfs/+/23034/
> Change-Id: I9f2478b12a281f6e052035c0563c40543493a3fc
> Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
Change-Id: I9f2478b12a281f6e052035c0563c40543493a3fc
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
|
|
|
|
|
|
|
| |
Fixes: bz#1726935
Change-Id: If682cd271c07fdcb62d77ff007ff502ee4a28501
Signed-off-by: hari gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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#1729952
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://review.gluster.org/c/glusterfs/+/22913 added a new SELinux hook
script as a post add-brick operation to label new brick paths. But the
change failed to install and package new script. Therefore making
necessary changes to Makefile and spec file to get it installed and
packaged.
Backport of:
> Change-Id: I67b8f4982c2783c34a4bc749fb4387c19a038225
> fixes: bz#1717953
> Signed-off-by: Anoop C S <anoopcs@redhat.com>
Change-Id: I67b8f4982c2783c34a4bc749fb4387c19a038225
fixes: bz#1718227
Signed-off-by: Anoop C S <anoopcs@redhat.com>
(cherry picked from commit 647a1b83fa39a635b01fcba38a330485fcd6afdb)
|
|
|
|
|
|
|
|
|
|
|
|
| |
snapview server xlator makes use of "localhost" as the volfile server while
initing the new glfs instance to talk to a snapshot. While localhost is fine,
better use the same volfile server that was used to start the snapshot
daemon containing the snapview-server xlator.
Change-Id: I4485d39b0e3d066f481adc6958ace53ea33237f7
fixes: bz#1727984
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
(cherry picked from commit 36f6e6df0ff15d0464b869803710adca2b65e8ba)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... with out which volume creation fails with "volume create: <xyz>: failed:
Failed to create volume files"
>Fixes: bz#1716812
>Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
>Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Fixes: bz#1721105
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Dictionary object is not being unref'd when an error happens
in __glusterd_handle_cli_deprobe(). This patch addresses that problem.
Change-Id: I11e1f92d06dc9edd1260845256f435ea31ef1a87
fixes: bz#1683815
Signed-off-by: Vijay Bellur <vbellur@redhat.com>
(cherry picked from commit 16b4936696c8b602243513fbde0b20a1e8417432)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...otherwise this leads to a crash when volume status is run on a
heterogeneous mode.
> Fixes: bz#1723658
> Change-Id: I0d39f412b2e5e9d3ef0a3462b90b38bb5364b09d
> Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
(cherry picked from commit a72452fcf90679b28baec12d2769cbaa982bb4e4)
Fixes: bz#1728126
Change-Id: I0d39f412b2e5e9d3ef0a3462b90b38bb5364b09d
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While sending upcall notifications via synctasks, the argument used to
carry relevant data for these tasks is not initialized properly. This patch
is to fix the same.
This is backport of below mainline fix -
> fixes: bz#1718316
> patch url: https://review.gluster.org/#/c/glusterfs/+/22839/
> Signed-off-by: Soumya Koduri <skoduri@redhat.com>
Change-Id: I9fa8f841e71d3c37d3819fbd430382928c07176c
fixes: bz#1720635
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
(cherry picked from commit bc6fd4cfa6ed34de3ffc02e2279fcc713f80f530)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For nameless LOOKUPs, server creates a new inode which shall
remain invalid until the fop is successfully processed post
which it is linked to the inode table.
But incase if there is an already linked inode for that entry,
it discards that newly created inode which results in upcall
notification. This may result in client being bombarded with
unnecessary upcalls affecting performance if the data set is huge.
This issue can be avoided by looking up and storing the upcall
context in the original linked inode (if exists), thus saving up on
those extra callbacks.
This is backport of below mainline fix -
> fixes: bz#1718338
> patch url: https://review.gluster.org/#/c/glusterfs/+/22840/
> Signed-off-by: Soumya Koduri <skoduri@redhat.com>
Change-Id: I044a1737819bb40d1a049d2f53c0566e746d2a17
fixes: bz#1720633
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_real_filename is implemented as a virtual extended attribute to help
Samba implement the case-insensitive but case preserving SMB protocol
more efficiently. It is implemented as a getxattr call on the parent directory
with the virtual key of "get_real_filename:<entryname>" by looking for a
spelling with different case for the provided file/dir name (<entryname>)
and returning this correct spelling as a result if the entry is found.
Originally (05aaec645a6262d431486eb5ac7cd702646cfcfb), the
implementation used the ENOENT errno to return the authoritative answer
that <entryname> does not exist in any case folding.
Now this implementation is actually a violation or misuse of the defined
API for the getxattr call which returns ENOENT for the case that the dir
that the call is made against does not exist and ENOATTR (or the synonym
ENODATA) for the case that the xattr does not exist.
This was not a problem until the gluster fuse-bridge was changed
to do map ENOENT to ESTALE in 59629f1da9dca670d5dcc6425f7f89b3e96b46bf,
after which we the getxattr call for get_real_filename returned an
ESTALE instead of ENOENT breaking the expectation in Samba.
It is an independent problem that ESTALE should not leak out to user
space but is intended to trigger retries between fuse and gluster.
But nevertheless, the semantics seem to be incorrect here and should
be changed.
This patch changes the implementation of the get_real_filename virtual
xattr to correctly return ENOATTR instead of ENOENT if the file/directory
being looked up is not found.
The Samba glusterfs_fuse vfs module which takes advantage of the
get_real_filename over a fuse mount will receive a corresponding change
to map ENOATTR to ENOENT. Without this change, it will still work
correctly, but the performance optimization for nonexisting files is
lost. On the other hand side, this change removes the distinction
between the old not-implemented case and the implemented case.
So Samba changed to treat ENOATTR like ENOENT will not work correctly
any more against old servers that don't implement get_real_filename.
I.e. existing files will be reported as non-existing
Backport of:
> Change-Id: I971b427ab8410636d5d201157d9af70e0d075b67
> fixes: bz#1722977
> Signed-off-by: Michael Adam <obnox@samba.org>
Change-Id: I971b427ab8410636d5d201157d9af70e0d075b67
fixes: bz#1723659
Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit dc1b87fcfef08c9497b0c02b2410c9d18bbc2dba)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of:
> Change-Id: Ifd8ae5eeb91b968cc1a9a9b5d15844c5233d56db
> fixes: bz#1717953
> Signed-off-by: Anoop C S <anoopcs@redhat.com>
Change-Id: Ifd8ae5eeb91b968cc1a9a9b5d15844c5233d56db
fixes: bz#1718227
Signed-off-by: Anoop C S <anoopcs@redhat.com>
(cherry picked from commit 582f91fcad42b6b7da653d2a587d196a7a1e0204)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of:
> BUG: bz#1705884
> Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53
> Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
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#1716871
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
(cherry picked from commit 400b66d568ad18fefcb59949d1f8368d487b9a80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of:
> BUG: bz#1705884
> Change-Id: I2c1ddab17457f45e27428575ad16fa678fd6c0eb
> Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
... by holding delta_blocks in 64-bit int as opposed to 32-bit int.
Change-Id: I2c1ddab17457f45e27428575ad16fa678fd6c0eb
updates: bz#1716871
Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
(cherry picked from commit e18e98659dd2b41eb59cf593fd625f1821a20abf)
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid the failure wait to run hook script S13create-subdir-mounts.sh
after executed add-brick command by test case.
Change-Id: I063b6d0f86a550ed0a0527255e4dfbe8f0a8c02e
fixes: bz#1726327
> fixes: bz#1720993
> Signed-off-by: Mohit Agrawal <moagrawal@redhat.com>
> (Cherry pick from commit 25ad5aca23b257cdd129cd1d4518b048fbba87bb)
> (Reviewed on upstream link https://review.gluster.org/#/c/glusterfs/+/22877/)
|
|
|
|
|
|
|
|
|
|
|
| |
>Backport of https://review.gluster.org/#/c/glusterfs/+/22948/
>Change-Id: I0cb5320fea71306e0283509ae47024f23874b53b
>fixes: bz#1723761
Change-Id: I0cb5320fea71306e0283509ae47024f23874b53b
fixes: bz#1724558
Signed-off-by: Jiffin Tony Thottan <jthottan@redhat.com>
(cherry picked from commit 7d8be567f2f904fc74d0990ebce2e8afbedab918)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a memleak in dht_rename_cbk when creating
a linkto file.
>Change-Id: I705adef3cb79e33806520fc2b15558e90e2c211c
>fixes: bz#1722698
Change-Id: I705adef3cb79e33806520fc2b15558e90e2c211c
fixes: bz#1726294
Signed-off-by: N Balachandran <nbalacha@redhat.com>
(cherry picked from commit 532b0fc8b1ace9ad48fdaf643e0b1a34020b6cd8)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two problems have been identified that caused that gluster's memory
usage were twice higher than required.
1. An off by 1 error caused that all objects allocated from the memory
pools were taken from a pool bigger than required. Since each pool
corresponds to a size equal to a power of two, this was wasting half
of the available memory.
2. The header information used for accounting on each memory object was
not taken into consideration when searching for a suitable memory
pool. It was added later when each individual block was allocated.
This made this space "invisible" to memory accounting.
Credits: Thanks to Nithya Balachandran for identifying this problem and
testing this patch.
Backport of:
> BUG: 1722802
> Change-Id: I90e27ad795fe51ca11c13080f62207451f6c138c
> Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
Fixes: bz#1724210
Change-Id: I90e27ad795fe51ca11c13080f62207451f6c138c
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of:
> BUG: 1193929
> Change-Id: I245c065b209bcce5db939b6a0a934ba6fd393b47
> Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Updates: bz#1724210
Change-Id: I245c065b209bcce5db939b6a0a934ba6fd393b47
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Removed some code that was not needed. It did not really do anything.
2. CALLOC -> MALLOC in one place.
Compile-tested only!
Backport of:
> BUG: 1193929
> Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
> Change-Id: I4419161e1bb636158e32b5d33044b06f1eef2449
Updates: bz#1724210
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
Change-Id: I4419161e1bb636158e32b5d33044b06f1eef2449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Backport of:
> BUG: 1193929
> Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50
> Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
Updates: bz#1724210
Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
On a EC volume, during upgrade from the older version where
ctime feature is not enabled(or not present) to the newer
version where the ctime feature is available (enabled default),
the self heal hangs and doesn't complete.
Cause:
The ctime feature has both client side code (utime) and
server side code (posix). The feature is driven from client.
Only if the client side sets the time in the frame, should
the server side sets the time attributes in xattr. But posix
setattr/fseattr was not doing that. When one of the server
nodes is updated, since ctime is enabled by default, it
starts setting xattr on setattr/fseattr on the updated node/brick.
On a EC volume the first two updated nodes(bricks) are not a
problem because there are 4 other bricks with consistent data.
However once the third brick is updated, the new attribute(mdata xattr)
will cause an inconsistency on metadata on 3 bricks, which
prevents the file to be repaired.
Fix:
Don't create mdata xattr with utimes/utimensat system call.
Only update if already present.
Backport of:
> Patch: https://review.gluster.org/22858
> Change-Id: Ieacedecb8a738bb437283ef3e0f042fd49dc4c8c
> BUG: 1720201
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Change-Id: Ieacedecb8a738bb437283ef3e0f042fd49dc4c8c
fixes: bz#1722805
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
If ctime and uss enabled, tar still complains with 'file
changed as we read it'
Cause:
To clear nfs cache (gluster-nfs), the ctime was incremented
in snap-view client on stat cbk.
Fix:
The ctime should not be incremented manually. Since gluster-nfs
is planning to be deprecated, this code is being removed to
fix the issue.
Backport of:
> Patch: https://review.gluster.org/2861/
> Change-Id: Iae7f100c20fce880a50b008ba716077350281404
> BUG: 1720290
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 01846e7b9b0b92e4a10f5cbcc921bad90441660d)
Change-Id: Iae7f100c20fce880a50b008ba716077350281404
fixes: bz#1721783
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Backport of:
> Change-Id: I6d67f23979e7edd2695bdc6aab2997dae4a4060a
> BUG: 1700865
> Signed-off-by: Susant Palai <spalai@redhat.com>
Change-Id: I6d67f23979e7edd2695bdc6aab2997dae4a4060a
Updates: bz#1724210
Signed-off-by: Susant Palai <spalai@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of:
> Change-Id: I3bbda719027b45e1289db2e6a718627141bcbdc8
> BUG: 1193929
> Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
Change-Id: I3bbda719027b45e1289db2e6a718627141bcbdc8
updates: bz#1724210
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following files are fixed.
tests/bugs/distribute/overlap.py
tests/utils/changelogparser.py
tests/utils/create-files.py
tests/utils/gfid-access.py
tests/utils/libcxattr.py
Backport of:
> Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
> BUG: 1193929
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
updates: bz#1679998
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
| |
Fixes: bz#1718555
Change-Id: Ibe540110156d70dc1bf308eccd08d49339f4ef7a
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EC was ignoring lock contention notifications received while a lock was
being acquired. When a lock is partially acquired (some bricks have
granted the lock but some others not yet) we can receive notifications
from acquired bricks, which should be honored, since we may not receive
more notifications after that.
Since EC was ignoring them, once the lock was acquired, it was not
released until the eager-lock timeout, causing unnecessary delays on
other clients.
This fix takes into consideration the notifications received before
having completed the full lock acquisition. After that, the lock will
be releaed as soon as possible.
Backport of:
> BUG: bz#1708156
> Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
> Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
Fixes: bz#1714172
Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
>Change-Id: Ibd37b6ea82b781a1a266b95f7596874134f30079
>fixes: bz#1713730
>Signed-off-by: Amgad Saleh <amgad.saleh@nokia.com>
fixes: bz#1715012
Change-Id: I9a9877b6c32a1ccbd119301a4225808ddaa02de4
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
| |
Fixes: bz#1701203
Change-Id: Id105192610726e370fa977df2c29723201b94695
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gfid conflict resolution code path is not supposed
to hit in generic code path. But few of the heavy rename
workload (BUG: 1694820) makes it a generic case. So
logging the entries to be fixed as INFO floods the log
in these particular workloads. Hence convert them to DEBUG.
Backport of:
> Patch: https://review.gluster.org/22720
> BUG: 1709653
> Change-Id: I4d5e102b87be5fe5b54f78f329e588882d72b9d9
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
fixes: bz#1712223
Change-Id: I4d5e102b87be5fe5b54f78f329e588882d72b9d9
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Geo-rep sync hangs when tarssh is used as sync
engine at heavy workload.
Analysis and Root cause:
It's found out that the tar process was hung.
When debugged further, it's found out that stderr
buffer of tar process on master was full i.e., 64k.
When the buffer was copied to a file from /proc/pid/fd/2,
the hang is resolved.
This can happen when files picked by tar process
to sync doesn't exist on master anymore. If this count
increases around 1k, the stderr buffer is filled up.
Fix:
The tar process is executed using Popen with stderr as PIPE.
The final execution is something like below.
tar | ssh <args> root@slave tar --overwrite -xf - -C <path>
It was waiting on ssh process first using communicate() and then tar.
Note that communicate() reads stdout and stderr. So when stderr of tar
process is filled up, there is no one to read until untar via ssh is
completed. This can't happen and leads to deadlock.
Hence we should be waiting on both process parallely, so that stderr is
read on both processes.
Backport of:
> Patch: https://review.gluster.org/22684/
> Change-Id: I609c7cc5c07e210c504771115b4d551a2e891adf
> BUG: 1707728
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Change-Id: I609c7cc5c07e210c504771115b4d551a2e891adf
fixes: bz#1709738
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The arequal checkusm comparison was always returning
as successful, eventhough, if it was not. Fixed the same.
Backport of:
> Patch: https://review.gluster.org/22682
> Change-Id: I5083da25c0954126e452d06311d2d376f8540555
> BUG: 1707742
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 288cffd1ab7180cccfcdea36d0c469b9fa52108f)
Change-Id: I5083da25c0954126e452d06311d2d376f8540555
fixes: bz#1712220
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
When 'use_tarssh' is set to true, it exits with successful
message but the default 'rsync' was used as sync-engine.
The new config 'sync-method' is not allowed to set from cli.
Analysis and Fix:
The 'use_tarssh' config is deprecated with new
config framework and 'sync-method' is the new
config to choose sync-method i.e. tarssh or rsync.
This patch fixes the 'sync-method' config. The allowed
values are tarssh and rsync.
Backport of:
> Patch: https://review.gluster.org/22683
> Change-Id: I0edb0319cad0455b29e49f2f08a64ce324735e84
> BUG: 1707686
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Change-Id: I0edb0319cad0455b29e49f2f08a64ce324735e84
fixes: bz#1709737
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Geo-rep fails to sync the rename properly if destination exists.
It results in source to be remained on slave causing more number of
files on slave. Also heavy rename workload like logrotate caused
lot of ESTALE errors
Cause:
Geo-rep fails to sync rename if destination exists if creation
of source file also falls into single batch of changelogs being
processed. This is because, after fixing problematic gfids verifying
from master, while re-processing original entries, CREATE also was
re-processed causing more files on slave and rename to be failed.
Solution:
Entries need to be removed from retrial list after fixing
problematic gfids on slave so that it's not re-created again on slave.
Also treat ESTALE as EEXIST so that the error is properly handled
verifying the op on master volume.
Backport of:
> Patch: https://review.gluster.org/22519/
> Change-Id: I50cf289e06b997adddff0552bf2466d9201dd1f9
> BUG: 1694820
> Signed-off-by: Kotresh HR <khiremat@redhat.com>
> Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
Change-Id: I50cf289e06b997adddff0552bf2466d9201dd1f9
fixes: bz#1709734
Signed-off-by: Kotresh HR <khiremat@redhat.com>
|