IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
1 - setup-thin-arbiter.sh
To setup directory path for thin-arbiter. This is the path where replica id
file will be placed and used by TA process.
By default it will be /mnt/thin-arbiter. It is better to use default path
and once set it should not be changed.
2 - gluster-ta-volume.service
This is the Unit file used by systemd to start and keep the thin-arbiter
process running.
3 - thin-arbiter.vol
This is the default volume file for thin-arbiter. It will be used to start
thin-arbiter process. This should not be modified by user except the
directory path which can be modified using [1].
Change-Id: I68f2164f24adfa326c1d1a7a98c6ac4ff04ed553
fixes: bz#1579786
Signed-off-by: Ashish Pandey <aspandey@redhat.com>
Problem: In case of error(ESTALE/ENOENT) dht_revalidate_cbk
throws "dict is null" error because xattr is not available
Solution: To avoid the logs update condition in dht_revalidate_cbk
and dht_lookup_dir_cbk
BUG: 1583565
Change-Id: Ife6b3eeb6d91bf24403ed3100e237bb5d15b4357
fixes: bz#1583565
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
setattr, posix-acl and selinux changes on a file can revoke permission
to open the file after permission changes. To prevent that, make sure
the pending fd is opened before winding down setattr or setxattr (for
posix-acl and selinux) calls.
Change-Id: Ib0b91795d286072e445190f9a1b3b1e9cd363282
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
fixes: bz#1405147
script can be used to for 3 purposes
1) Extract marker xattr from the backend with a crawl (for analysis)
2) Report anomalies in accounting by comparing stat based accounting
with marker translator's accounting
3) Fix anomalies in the FS by marking the anamolous directories dirty
and having them heal in a bottom up fashion over the directory tree.
Change-Id: Ib4d4a6d1886d7332c80d5a93f7afccaa0f52ab58
fixes: #390
Signed-off-by: Sanoj Unnikrishnan <sunnikri@redhat.com>
Signed-off-by: Hari Gowtham <hgowtham@redhat.com>
Problem:
socket_server_event_handler() may call rpc_transport_unref() for a
socket which may fail registration with the event sub-system.
This causes an assert to fail in event_unregister_epoll_common()
Solution:
Conditionally cleanup event slot only if slot index >= 0
Change-Id: I6ca7c133712e894adc335c7763879691b7e4b213
fixes: bz#1582704
BUG: 1582704
Signed-off-by: Milind Changire <mchangir@redhat.com>
This is to make sure applications that read and write on different fds
of the same file work.
This patch also fixes two other issues:
1. while iterating over the list of open fds on an inode, initialize
tmp_file to 0 for each iteration before fd_ctx_get to make sure we
don't carry over the history from previous iterations.
2. remove flushing of cache in flush and fsync as by themselves, they
don't modify the data
Change-Id: Ib9959eb73702a3ebbf90badccaa16b2608050eff
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
This reverts commit 9340b3c7a6c8556d6f1d4046de0dbd1946a64963.
operations/writes across different fds of the same file cannot be
considered as independent. For eg., man 2 fsync states,
<man 2 fsync>
fsync() transfers ("flushes") all modified in-core data of
(i.e., modified buffer cache pages for) the file referred to by the
file descriptor fd to the disk device
</man>
This means fsync is an operation on file and fd is just a way to reach
file. So, it has to sync writes done on other fds too. Patch
9340b3c7a6c, prevents this.
The problem fixed by patch 9340b3c7a6c - a flush on an fd is hung on a
failed write (held in cache for retrying) on a different fd - is
solved in this patch by making sure __wb_request_waiting_on considers
failed writes on any fd as dependent on flush/fsync on any fd (not
just the fd on which writes happened) opened on the same file. This
means failed writes on any fd are either synced or thrown away on
witnessing flush/fsync on any fd of the same file.
Change-Id: Iee748cebb6d2a5b32f9328aff2b5b7cbf6c52c05
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: bz#1512691
Problem: We introduced lock timer in mgmt v3, which will realease
the lock after 3 minutes from command execution. Some commands related
to heal/profile will take more time to execute. For these comands
timeout is set to 10 minutes. As the lock timer is set to 3 minutes
glusterd is releasing the lock after 3 minutes. That means locks are
released before the command is completed its execution.
Solution: Pass a timeout parameter from cli to glusterd, when there
is a change in default timeout value(i.e, default timeout value can
be changed through command line or for the commands related to profile/heal
we will change the default timeout value to 10 minutes.) glusterd will
set the lock timer timeout according to the timeout value passed.
Change-Id: I7b7a9a4f95ed44aca39ef9d9907f546bca99c69d
fixes: bz#1577731
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
Thanks to Pranith for the example. Following is the race we are trying
to solve with this patch.
1) We have a file with content 'abc'
2) lookup and writev which replaces 'abc' with 'def' comes. Lookup
fetches abc but yet to update the cache, and then immediately
writev is wound which zeros out the cache. Now lookup_cbk updates
the buffer with 'abc' even though on disk it is 'def'. Now writev
completes and returns to application.
3) application does a readv which will be fetched from quick-read as
'abc'.
Change-Id: I9a9cab9c99652aa6d17230a4fe4dc034ec502b1b
BUG: 1390050
Updates: bz#1390050
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
An entry from readdirp might get renamed just before migration leading to
lookup failures. For such lookup failure, remove-brick process does not
see any increment in failure count. Though there is a warning message
after remove-brick commit for the user to check in the decommissioned brick
for any files those are not migrated, it's better to increase the failure count
so that user can check in the decommissioned bricks for files before commit.
Note: This can result in false negative cases for rm -rf interaction with
remove-brick op, where remove-brick shows non-zero failed count, but the
entry was actually deleted by user.
Fixes :bz#1580269
Change-Id: Icd1047ab9edc1d5bfc231a1f417a7801c424917c
fixes: bz#1580269
Signed-off-by: Susant Palai <spalai@redhat.com>
Lookup on root was sending "/" as the path.
This will break the basename calculation in
loc_copy and hence lookup on root was failing
if the loc_copy was involved in the stack.
With ctime, a first lookup on root initiates
a metadata self heal because of ctime xattr
not being same on all afr subvolumes. This
results in loc_copy and hence the failure
of lookup.
Fix would be to send path with "." for the root.
fixes: bz#1582516
Change-Id: Iafe4b99f249a4f5034ad34c1d30590de0e35aa0d
Signed-off-by: Kotresh HR <khiremat@redhat.com>
The ./run-tests-in-vagrant.sh script does not return the correct exit
status. Even if the tests in the Vagrant VM fail, the script returns
success. This throws off the expectations that any regular testers (or
CI) have.
BUG: 1546103
Change-Id: I7f00903f9fe4ef3be8ba80db0f9aa8d412502b86
Signed-off-by: Niels de Vos <ndevos@redhat.com>
There seems to be races which are not fixed by commit
9704d203f0. Though the test itself is not bad, it is failing very
frequently. So, till the issue is fixed, marking this test as bad.
updates: bz#1543279
Change-Id: I4a5869da1586178914ffb9563414879e6beab183
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
missing __THROW on pub function decls needed for C++
Change-Id: Ia0ff09d311741e4cdc8ef171e07bbd56c24b9260
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
Problem: Sometime br-state-check.t crash while runnning
for brick multiplex and command in test case is
taking 2 minutes for detach a brick
Solution: Update code in changelog xlator specific to wait
on all connection before cleanup rpc threads and
cleanup rpc object only in non brick mux scenario
BUG: 1577672
Change-Id: I16e257c1e127744a815000b87bd8b7b8d9c51e1b
fixes: bz#1577672
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
If certain builds have readdir-ahead disabled by default, the
test case fails, as it asumes readdir-ahead is enabled by
default. Hence explicitly enabling readdir-ahead.
Change-Id: Ib5bef266707c2c557aeb2cf2ffbf4d0c92025c46
fixes: bz#1582051
Signed-off-by: Poornima G <pgurusid@redhat.com>
With ctime feature enabled, the mtime is not
updated when it's set to time older than the
existing one. Fixed the same. But the ctime
is not allowed to change to older dates.
fixes: bz#1581035
Change-Id: If520922df42d6ce084c8df3046c138f8367164e5
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Currently plugins for cloudsync will be using it to write back data
downloaded from remote store/cloud.
Change-Id: I59f10bebed21b19568c94cbf29e3d536d5570749
Updates: #387
Signed-off-by: Susant Palai <spalai@redhat.com>
With ctime feature enabled, the gfid is
not healing on first lookup. The fresh
file logic depends on ctime and it was
fetching from backend instead of xattr
with ctime feature enabled. Fixed the
same.
Also fixed a possible hang with inode lock
Change-Id: I020875c0462b284d6fa0e68304a422fa3d6a3e73
fixes: bz#1580532
Signed-off-by: Kotresh HR <khiremat@redhat.com>
As of now, even for readdirp, posix is unwinding with readdir
signature.
Change-Id: I6440c8a253c5d78bbcc97043e4e6e208e3d47cd1
fixes: bz#1581345
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
With ctime feature enabled, atime is not
being updated for a hardlink when the file
is accessed.
e.g., touch -a <hardlink_file> fails to
update atime. This patch fixes the same.
fixes: bz#1580529
Change-Id: I2201c88d502d0070300a1f5023af1b36951284ec
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Corrected the name of the xattr and fixed
the code to log an error only if op_errno
is not ENODATA or ENOATTR.
Change-Id: I42c5b1d838eec586ac7bed2471eb1d27ff09a9ea
fixes: bz#1580238
Signed-off-by: N Balachandran <nbalacha@redhat.com>
also provide an option for pass-through to enable/disable xlator
fixes: #421
Change-Id: Ie30a91ad09620db62ab07b797e23123fd1200d1f
Signed-off-by: Amar Tumballi <amarts@redhat.com>
1. Successful rename was not updating ctime.
Fixed the same.
2. Successful unlink when link count is more than 1
was not updating ctime. Fixed the same.
3. Copy ctime and flags during frame copy.
fixes: bz#1580020
Change-Id: Ied47275a36aea60254b2add7a59128a9c83b3645
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Since readdirp acts as a batched lookup for all dentries it reads, it
has to synchronize with any entry operation within the directory being
read.
Change-Id: I923a6ebd21856dbaa5fa5db4a26a29b7b29b3159
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
fixes: #421
The auth_value was being reset to AUTH_GLUSTERFS_v2
during rpc disconnect. It shoud not be reset. The
disconnect during portmap request can race with
handshake. If handshake happens first and
disconnect later, auth_value would set to default
value and it never sets back to actual auth_value
fixes: bz#1579276
Change-Id: Ib46c9e01a97f6defb3fd1e0423fdb4b899b4a361
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Multiple pre-op xattrop can be simultaneously being processed. On the cbk
it was checked if the fop was waiting for some specific data (like size and
version) and, if so, it was assumed that this answer should contain that
data.
This is not true, since a fop can be waiting for some data, but it may come
from the xattrop of another fop.
This patch differentiates between needing some information and providing it.
This is related to parallel writes. Disabling them fixed the problem, but
also prevented concurrent reads. A change has been made so that disabling
parallel writes still allows parallel reads.
Fixes: bz#1578325
Change-Id: I74772ad6b80b7b37805da93d5ec3ae099e96b041
Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
This patch brings the configuration option for plugins.
For new plugins, an entry has to be created in to cs_plugin structure e.g.
struct cs_plugin plugins[] = {
{
.name = "amazons3",
.library = "libamazons3.so",
.description = "amazon s3 store."
},
{.name = NULL},
};
Library field describes the name of the shared library for the plugin.
To configure plugin type "feature.cloudsync-storetype" option need
to be set to the remote-store type. e.g.
gluster volume set VOLNAME cloudsync-storetype amazons3. This should be same
as the ".name" field in cs_plugin structure.
cs_init will pick this up in run time to load the plugin.
Change-Id: I2cec10b206f71ac4e71d472631a3a5badf278b59
fixes: bz#1576842
Signed-off-by: Susant Palai <spalai@redhat.com>
Problem:
In the .t, when the only good brick was brought down, writes on the fd were
still succeeding on the bad bricks. The inflight split-brain check was
marking the write as failure but since the write succeeded on all the
bad bricks, afr_txn_nothing_failed() was set to true and we were
unwinding writev with success to DHT and then catching the failure in
post-op in the background.
Fix:
Don't wind the FOP phase if the write_subvol (which is populated with readable
subvols obtained in pre-op cbk) does not have at least 1 good brick which was up
when the transaction started.
Note: This fix is not related to brick muliplexing. I ran the .t
10 times with this fix and brick-mux enabled without any failures.
Change-Id: I915c9c366aa32cd342b1565827ca2d83cb02ae85
updates: bz#1577672
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
Crypt xlator occasionaly uses local storage in it's call frame.
These frames are managed with common macroes, which does not take
care about cleaning up such local storages. The fix is similar to
the other xlators' solution. A crypt specific macro handles the
cleaning of the local storage when it is allocated.
Change-Id: Ibb5b91551fbe70905e9c8c688d999fe702433e35
fixes: bz#1564419
Signed-off-by: Gergo Huszty <gergo.huszty@nokia.com>
Work on #208 having been been merged, we have obtained
means to associate arbitrary ctimes with files, so
we can handle setattr ctime payload with proper semantics.
Updates: #435
Change-Id: I7302a3ee2574ca9bba605c7a8586c16c452f82c1
Signed-off-by: Csaba Henk <csaba@redhat.com>
Removed EIO from the list of errnos that triggered
a migrate check task.
Change-Id: I7f89c7a16056421588f1af2377cebe6affddcb47
fixes: bz#1578823
Signed-off-by: N Balachandran <nbalacha@redhat.com>
Issue: When parallel-readdir is enabled, readdir-optimize automatically
stops working because of a bug in rda_opendir.
RCA: In rda_opendir, the xattrs that indicate readdir-optimize or not
is sent in xdata. This xdata is sent to all the readdirp prefetch
calls. A dict_ref is taken on xdata and kept in rda_opendir to be
used by rda_fill_fd, but dht_opendir deletes some elements in xdata
after calling rda_opendir. Hence dict_ref is not a right choice here,
dict_copy needs to used.
Change-Id: Ie7cc7ceb03117dd4179ef7905647f2f123f94966
fixes: bz#1578650
Signed-off-by: Poornima G <pgurusid@redhat.com>
noticed that server protocol actually logs all the errors for
removexattr as INFO, instead of WARNING like client, and hence,
doesn't create a confusion in user.
updates: bz#1576418
Change-Id: Ia6681e9ee433fda3c77a4509906c78333396e339
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Csaba found that statedump of fusemount has two instances of
each of the mem-accounting information. On debugging, I realized
that statedump is called for both ctx->master and ctx->active.
Since ctx->active is a sub-graph of ctx->master, there are duplicate
entries. Fixed this part to prevent duplication in this patch.
fixes bz#1578721
BUG: 1578721
Change-Id: I5a63b4f5933d4d720ac010c58e6dee3b27067d42
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Problem: gluster volume info --xml is showing same uuid to all
the bricks of a tier volume.
Solution: While iterating over hot/cold bricks of a tier volume, use
correct iterator.
Fixes: bz#1577627
Change-Id: Icf6a9c2a10b9da453abc262a57b7884d6638e3ed
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
Problem: Sometimes brick process is getting crash at the time
of calling inode_unref in fd_destroy
Solution: Brick process is getting crash because inode is already
free by xlator_mem_cleanup call by server_rpc_notify.To
resolve the same move code specific to call transport_unref
in last in free_state.
BUG: 1577574
Change-Id: Ia517c230d68af4e929b6b753e4c374a26c39dc1a
fixes: bz#1577574
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
Fix crash where session_name is referenced
before assignment. Well, this is a corner
case where the geo-rep session exists and
the status output doesn't show any rows.
This might happen when glusterd is down
or when the system is in inconsistent state
w.r.t glusterd.
fixes: bz#1576179
Change-Id: Iec1557e01b35068041b4b3c1aacee2bfa0e05873
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Using strdump instead of gf_strdup crashes
during free if mempool is being used.
gf_free checks the magic number in the
header which will not be taken care if
strdup is used.
fixes: bz#1576392
Change-Id: Iab36496554b838a036af9d863e3f5fd07fd9780e
Signed-off-by: Kotresh HR <khiremat@redhat.com>
The xprt's dereferencing wasn't checked before using it for the
strcmp, which caused the segfault and crashed the brick process.
fix: Check every deferenced variable before using it.
Change-Id: I7f705d1c88a124e8219bb877156fadb17ecf11c3
fixes: bz#1575864
Signed-off-by: hari gowtham <hgowtham@redhat.com>
Problem: In Geo-Rep setup excessive "dict is null" logs in
dht_discover_complete while xattr is NULL
Solution: To avoid the logs update a condition in dht_discover_complete
BUG: 1576767
Change-Id: Ic7aad712d9b6d69b85b76e4fdf2881adb0512237
fixes: bz#1576767
Signed-off-by: Mohit Agrawal <moagrawa@redhat.com>
