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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Revisiting http://review.gluster.org/#/c/11814/, which unintentionally
introduced warnings from libtool about the xlator .so names.
According to [1], the -module option must appear in the Makefile.am
file(s); if -module is defined in a macro, e.g. in configure(.ac),
then libtool will not recognize that this is a module and will emit a
warning.
[1]
http://www.gnu.org/software/automake/manual/automake.html#Libtool-Modules
Change-Id: Ifa5f9327d18d139597791c305aa10cc4410fb078
BUG: 1248669
Signed-off-by: Kaleb S KEITHLEY <kkeithle@redhat.com>
Reviewed-on: http://review.gluster.org/13003
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: soumya k <skoduri@redhat.com>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
ENOENT is a safe error for geo-replication in case of
rm -rf. RMDIR is recorded in changelog of each brick,
geo-rep processes all changelogs among which one will
succeed and rest will get ENOENT which can be ignored.
Similarly ENOENT can also be ignored in case of all
unlink operation during changelog replay that can
happen when worker goes down and comes back.
Change-Id: I6756f8f4c3fce7a159751a2bfce891ff16ad31a4
BUG: 1250009
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/11833
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
Reviewed-by: Milind Changire <mchangir@redhat.com>
Reviewed-by: Saravanakumar Arumugam <sarumuga@redhat.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
A regression failure generated a coredump on the glusterfs-client side:
(gdb) f 0
#0 0x00007fba6cd76432 in client_submit_request (this=0x7fba68006fc0,
req=0x7fba6579aa70, frame=0x7fba5c0058cc,
prog=0x7fba6cfb53c0 <clnt3_3_fop_prog>, procnum=41,
cbkfn=0x7fba6cd9206d <client3_3_release_cbk>,
iobref=0x0, rsphdr=0x0, rsphdr_count=0,
rsp_payload=0x0, rsp_payload_count=0, rsp_iobref=0x0,
xdrproc=0x7fba79801075 <xdr_gfs3_release_req>) at
/home/jenkins/root/workspace/rackspace-regression-2GB-triggered/xlators/protocol/client/src/client.c:324
324 frame->root->ngrps = ngroups;
(gdb) l
319 gf_msg_debug (this->name, 0, "rpc_clnt_submit failed");
320 }
321
322 if (!conf->send_gids) {
323 /* restore previous values */
324 frame->root->ngrps = ngroups;
325 if (ngroups <= SMALL_GROUP_COUNT)
326 frame->root->groups_small[0] = gid;
327 }
328
(gdb) p *frame->root
Cannot access memory at address 0x64185df000000000
After looking at this in more detail, the flow is like this:
client_submit_request()
|
'- rpc_clnt_submit() // on line 314
|
'- cbkfn() // = client3_3_release_cbk
|
:- STACK_DESTROY (frame->root);
.----'
.----'
|
:- frame->root->ngrps = ngroups; // on line 324
'
So, there is a use-after-free, and it is not needed to restore the
previous groups in frame->root.
Change-Id: I9e7d712183692ed92cfc2f75cd3c2781a9db20e2
BUG: 128128
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/12575
Reviewed-by: Dan Lambright <dlambrig@redhat.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
The current way we install and package header files for the -devel
package is a hack. This patch uses more conventional autoconf, libtool,
and rpmbuild idioms to package -devel headers and libraries.
Change-Id: I63ffb3460f5c12b6b355493bd00824ac9e5354c5
BUG: 1271907
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
Reviewed-on: http://review.gluster.org/12360
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Summary:
- Using sampling feature you can record details about every Nth FOP.
The fields in each sample are: FOP type, hostname, uid, gid, FOP priority,
port and time taken (latency) to fufill the request.
- Implemented using a ring buffer which is not (m/c) allocated in the IO path,
this should make the sampling process pretty cheap.
- DNS resolution done @ dump time not @ sample time for performance w/
cache
- Metrics can be used for both diagnostics, traffic/IO profiling as well
as P95/P99 calculations
- To control this feature there are two new volume options:
diagnostics.fop-sample-interval - The sampling interval, e.g. 1 means
sample every FOP, 100 means sample every 100th FOP
diagnostics.fop-sample-buf-size - The size (in bytes) of the ring
buffer used to store the samples. In the even more samples
are collected in the stats dump interval than can be held in this buffer,
the oldest samples shall be discarded. Samples are stored in the log
directory under /var/log/glusterfs/samples.
- Uses DNS cache written by sshreyas@fb.com (Thank-you!), the DNS cache
TTL is controlled by the diagnostics.stats-dnscache-ttl-sec option
and defaults to 24hrs.
Test Plan:
- Valgrind'd to ensure it's leak free
- Run prove test(s)
- Shadow testing on 100+ brick cluster
Change-Id: I9ee14c2fa18486b7efb38e59f70687249d3f96d8
BUG: 1271310
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/12210
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
various xlators and other components are invoking system calls
directly instead of using the libglusterfs/syscall.[ch] wrappers.
If not using the system call wrappers there should be a comment
in the source explaining why the wrapper isn't used.
Change-Id: I1f47820534c890a00b452fa61f7438eb2b3f667c
BUG: 1267967
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
Reviewed-on: http://review.gluster.org/12276
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
* The max number of inodes in the lru list of the inode table was being defined
in terms of memory units (GF_UNIT_MB) instead of number. And the description
of the option was also referring to it in memory units instead of number.
Change-Id: I48f07e7d2826406697eb2a13714ab22feae81d89
BUG: 1266883
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-on: http://review.gluster.org/12242
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
There are xlators which perform fops even before inode gets linked. Because of
this loc.gfid is preferred at the time of inodelk/entrylk but by the time
unlock can happen, inode could be linked with a different gfid than the one in
loc.gfid (because of the way dht was giving preference) Due to this unlock goes
on a different inode than the one we sent inodelk on, which leads to hang.
Credits to Pranith for the fix.
Change-Id: I7d162d44852ba876f35aa1bb83e4afdb184d85b9
BUG: 1266834
Signed-off-by: Ravishankar N <ravishankar@redhat.com>
Reviewed-on: http://review.gluster.org/12233
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
problem:
assuming gluster volume is already mounted (for gfapi: say client transport
connection has already established), now if somebody change the volume
permissions say *.allow | *.reject for a client, gluster should allow/terminate
the client connection based on the fresh set of volume options immediately,
but in existing scenario neither we have any option to set this behaviour nor
we take any action until and unless we remount the volume manually
solution:
Introduce 'dynamic-auth' option (default: on).
If 'dynamic-auth' is 'on' gluster will perform dynamic authentication to
allow/terminate client transport connection immediately in response to
*.allow | *.reject volume set options, thus if volume permissions have changed
for a particular client (say client is added to auth.reject list), his
transport connection to gluster volume will be terminated immediately.
Change-Id: I6243a6db41bf1e0babbf050a8e4f8620732e00d8
BUG: 1245380
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-on: http://review.gluster.org/12229
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Normally GF_EVENT_CHILD_UP is dispatched after client
handshake. But we have some dead code in client_rpc_notify
which is assumed to do the same on receiving RPC_CLNT_CONNECT.
This dispatch is based on a condition whether "disable-handshake"
is enabled or not. Since we require client-handshake everytime
we have a connect this check for "disable-handshake" is invalid
and no longer required. Moreover this option is never handled
in any of the translators.
Change-Id: Ic862d6ac08cd3b18cf231f50140cd00e84e52ca0
BUG: 1227667
Signed-off-by: Anoop C S <anoopcs@redhat.com>
Reviewed-on: http://review.gluster.org/12170
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
We've been lucky that we haven't had any symbol collisions until now.
Now we have a collision between the snapview-client's svc_lookup() and
libntirpc's svc_lookup() with nfs-ganesha's FSAL_GLUSTER and libgfapi.
As a short term solution all the snapview-client's FOP methods were
changed to static scope. See http://review.gluster.org/11805. This
works in snapview-client because all the FOP methods are defined in
a single source file. This solution doesn't work for other xlators
with FOP methods defined in multiple source files.
To address this we link with libtool's '-export-symbols $symbol-file'
(a wrapper around `ld --version-script ...` --- on linux anyway) and
only export the minimum required symbols from the xlator sharedlib.
N.B. the libtool man page says that the symbol file should be named
foo.sym, thus the rename of *.exports to *.sym. While foo.exports
worked, we will follow the documentation.
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
BUG: 1248669
Change-Id: I1de68b3e3be58ae690d8bfb2168bfc019983627c
Reviewed-on: http://review.gluster.org/11814
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: soumya k <skoduri@redhat.com>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
When grace-timer is initialized via server/client init,
the default or reconfigured value for grace-timeout is
displayed incorrectly in both server and client logs.
This is because we use gf_time_fmt() to format this
grace-timeout value with gf_timefmt_s as the time format
as shown below:
gf_time_fmt (timestr, sizeof timestr, conf->grace_ts.tv_sec,
gf_timefmt_s);
gf_timefmt_s format is a wrapper for %s format specification
used in strftime library call which populates the number
of seconds since the Epoch [1970-01-01 00:00:00 +0000 (UTC)].
But this particular format is dependent on timezone
[1970-01-01 05:30:00 +0530 (IST)]and thus displayed incorrectly
in logs.
Example:
For IST with default grace-timeout value 10, it is displayed
as -19790 which is calculated as follows,
1970-01-01 00:00:10 - 1970-01-01 05:30:00 = -19790 seconds.
Change-Id: I1bdf5d12b2167323f86f0ca52a37ffb316b3f0a2
BUG: 1227667
Signed-off-by: Anoop C S <anoopcs@redhat.com>
Reviewed-on: http://review.gluster.org/11930
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra Talur <rtalur@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
If a looked up object is removed from the backend, then upon getting a
revalidated lookup on that object ENOENT error is received. protocol/server
xlator handles it by removing dentry upon which ENOENT is received. But the
inode associated with it still remains in the inode table, and whoever does
nameless lookup on the gfid of that object will be able to do it successfully
despite the object being not present.
For handling this issue, upon getting ENOENT on a looked up entry in revalidate
lookups, protocol/server should forget the inode as well.
Though removing files directly from the backend is not allowed, in case of
objects corrupted due to bitrot and marked as bad by scrubber, objects are
removed directly from the backend in case of replicate volumes, so that the
object is healed from the good copy. For handling this, the inode of the bad
object removed from the backend should be forgotten. Otherwise, the inode which
knows the object it represents is bad, does not allow read/write operations
happening as part of self-heal.
Change-Id: I23b7a5bef919c98eea684aa1e977e317066cfc71
BUG: 1238188
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-on: http://review.gluster.org/11489
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Adding some log messages to protocol client and server to
ease the debugging process.
Change-Id: I84a05fcde7189d6e6ad5c37c1bbffb148d123517
BUG: 1227667
Signed-off-by: Anoop C S <anoopcs@redhat.com>
Reviewed-on: http://review.gluster.org/11903
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
The @owner argument tells RPC layer the xlator that owns
the connection and to which xlator THIS needs be set during
network notifications like CONNECT and DISCONNECT.
Code paths that originate from the head of a (volume) graph and use
STACK_WIND ensure that the RPC local endpoint has the right xlator saved
in the frame of the call (callback pair). This guarantees that the
callback is executed in the right xlator context.
The client handshake process which includes fetching of brick ports from
glusterd, setting lk-version on the brick for the session, don't have
the correct xlator set in their frames. The problem lies with RPC
notifications. It doesn't have the provision to set THIS with the xlator
that is registered with the corresponding RPC programs. e.g,
RPC_CLNT_CONNECT event received by protocol/client doesn't have THIS set
to its xlator. This implies, call(-callbacks) originating from this
thread don't have the right xlator set too.
The fix would be to save the xlator registered with the RPC connection
during rpc_clnt_new. e.g, protocol/client's xlator would be saved with
the RPC connection that it 'owns'. RPC notifications such as CONNECT,
DISCONNECT, etc inherit THIS from the RPC connection's xlator.
Change-Id: I9dea2c35378c511d800ef58f7fa2ea5552f2c409
BUG: 1235582
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/11436
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
This test sets the lru limit of the inode table to 1 and checks if inode forgets
and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).
Change-Id: I1fa25fa2d31dda8d26e8192562e896e5bddd0381
BUG: 1244613
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-on: http://review.gluster.org/11718
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
The basic problem is that gf_authenticate abused global variables to
pass info through dict_foreach. This is not thread-safe, but it wasn't
affecting most people until multi-threaded epoll came along. Now, if
two threads get into this code at the same time - and there's nothing to
prevent it - one of them could free one of the dicts involved while the
other is still using it.
The fix is to pass this same information using a temporary structure
instead of globals. This makes the code smaller and more efficient too.
Change-Id: I72cccc440bb40d5f7ff695250dd014762c7efb73
BUG: 1247765
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/11780
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Commit 379dbbfd changed the log level of an expected error message from
GF_LOG_DEBUG to '0'. This causes the message to always get logged. It is
intended to log the warning when the xattr could not be removed (but
exists), removing a non-existing xattr is sufficient as debug.
BUG: 1246736
Change-Id: If11d15d699e8152cc32e0c0c1d65b587c5c48892
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/11759
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Joe Julian <me@joejulian.name>
Tested-by: Joe Julian <me@joejulian.name>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
GlusterD or a brick would crash when encrypted transport was enabled and
an unencrypted client tried to connect to them. The crash occured when
GlusterD/server tried to remove the transport from their xprt_list due
to a DISCONNECT event. But as the client transport's list head wasn't
inited, the process would crash when list_del was performed.
Initing the client transports list head during acceptence, prevents this
crash.
Also, an extra check has been added to the GlusterD and Server
notification handlers for client DISCONNECT events. The handlers will
now first check if the client transport is a member of any list.
GlusterD and Server DISCONNECT event handlers could be called without
the ACCEPT handler, which adds the transport to the list, being called.
This situation also occurs when an unencrypted client tries to establish
a connection with an encrypted server.
Change-Id: Icc24a08d60e978aaa1d3322e0cbed680dcbda2b4
BUG: 1243774
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/11692
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
protocol/server has to resolve the inode before continuing with any fop coming
from the clients. For resolving it, server xlator was using the same dict
associated with the fop. It causes problems in some situations.
If a directory's inode was forgotten because of lru limit being exceeded, then
when a create fop comes for an entry within that directory, server tries to
resolve it. But since the parent directory's inode is not found in the inode
table, it tries to do a hard resolve by doing a lookup on the parent gfid.
If any xlator below server wants to get some extended attributes whenever
lookup comes, then they set the new keys in the same dict that came along with
the create fop. Now, the lookup of the parent succeeds and the create fop
proceeds with the same dict (with extra keys present). posix xlaror creates
those xattrs that are present in the dict. Thus the xattrs which were not to
be present by default are also set as part of create. (Ex: bit-rot related
xattrs such as bad-file, version and sign xattrs)
Change-Id: I4bdad175a1d7a04a3aa36073667c556d6c260263
Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-on: http://review.gluster.org/11661
Reviewed-by: Vijaikumar Mallikarjuna <vmallika@redhat.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
We can only start recieving fops only when all xlators in graph are
initialized.
Change-Id: Id79100bab5878bb2518ed133c1118554fbb35229
BUG: 1236945
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Reviewed-on: http://review.gluster.org/11490
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com>
auth.ssl-allow wasn't being handled during reconfigure. This prevented
the ssl-allow list from being live reloaded.
Change-Id: If3435793a5684881b012de77cb254b1847b37810
BUG: 1238072
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/11487
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
rpc_transport entries(xprt) are added to the conf->xprt_list
during client connection with the server. But the client object is created
and assigned to that transport object only during GF_HANDSK_SETVOLUME. Hence
till that period, there could be xprt entries in the xprt_list without client
associated with it. Added a check to validate the client object during upcall
notify.
Change-Id: I11e2fcd8b0a67e35302ede478b777b72d1973456
BUG: 1235542
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
Reviewed-on: http://review.gluster.org/11411
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
On account of a lock reacquire failure [in clnt_release_reopen_fd()]
the return value, on submitting the client request for release of
reopened fd, is not honoured correctly.
Change-Id: Iff11523b2cc6f284e806855f32a13d8c4432f1c6
BUG: 1227667
Signed-off-by: Anoop C S <achiraya@redhat.com>
Reviewed-on: http://review.gluster.org/11088
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Tested-by: Raghavendra G <rgowdapp@redhat.com>
clnt_mark_fd_bad() is no longer used to mark the fd bad. Instead
we make use of client_mark_fd_bad() to do the same.
Change-Id: I09af892d8c0c5d1cf853ff020e8596c53d9539c0
BUG: 1227667
Signed-off-by: Anoop C S <achiraya@redhat.com>
Reviewed-on: http://review.gluster.org/11063
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Since the 3rd and 5th argument of gf_msg framework
prints the error string in case of strerror(),
5th argument is removed.
Change-Id: Ib1794ea2d4cb5c46a39311f0afcfd7e494540506
BUG: 1194640
Signed-off-by: Manikandan Selvaganesh <mselvaga@redhat.com>
Reviewed-on: http://review.gluster.org/11280
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Ignore logging in case of symlink and hardlink creation
errors, as these are safe errors with respect to
geo-replication.
Change-Id: I3b863fb03ae23dbea907e4dd9477ff85feecad70
BUG: 1225571
Signed-off-by: Saravanakumar Arumugam <sarumuga@redhat.com>
Reviewed-on: http://review.gluster.org/10957
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
There are valid use-cases where a "Stale filehandle" is expected. One of
these is deleting a file through NFS-Ganesha. When the "filename" is
deleted, Ganesha will stat the file-handle to update its attributes. The
file-handle would still be valid in the case where there are hardlinks.
There is no need to log "Stale filehandle" as Warning. It is perfectly
fine to have this logged as Debug.
Change-Id: Ib9006d95a5d1f7dd394bf5d5994ad70740ad4ab2
BUG: 1228731
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/11107
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: soumya k <skoduri@redhat.com>
Reviewed-by: jiffin tony Thottan <jthottan@redhat.com>
Instead of including config.h in each file, and have the additional
config.h included from the compiler commandline (-include option).
When a .c file tests for a certain #define, and config.h was not
included, incorrect assumtions were made. With this change, it can not
happen again.
BUG: 1222319
Change-Id: I4f9097b8740b81ecfe8b218d52ca50361f74cb64
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/10808
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
The structure 'rpcsvc_state', which maintains rpc server
state had no separate pointer to track the translator.
It was using the mydata pointer itself. So callers were
forced to send xlator pointer as mydata which is opaque
(void pointer) by function prototype.
'rpcsvc_register_init' is setting svc->mydata with xlator
pointer. 'rpcsvc_register_notify' is overwriting svc->mydata
with mydata pointer. And rpc interprets svc->mydata as
xlator pointer internally. If someone passes non xlator
structure pointer to rpcsvc_register_notify as libgfchangelog
currently does, it might corrupt mydata. So interpreting opaque
mydata as xlator pointer is incorrect as it is caller's choice
to send mydata as any type of data to 'rpcsvc_register_notify'.
Maintaining two different pointers in 'rpcsvc_state' for xlator
and mydata solves the issue.
Change-Id: I7874933fefc68f3fe01d44f92016a8e4e9768378
BUG: 1215161
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/10366
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Tested-by: Raghavendra G <rgowdapp@redhat.com>
Fix ignoring geo-rep safe errors in fuse layer
and also ignore logging in client translator
for mknod. Though it is rare, to happen with
mknod, it might happen with history crawl on
overlapping changelogs replay.
Change-Id: I7e145cd1dc53f04d444ad2e68e66e648be448e61
BUG: 1210562
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/10422
Tested-by: NetBSD Build System
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Aravinda VK <avishwan@redhat.com>
sssd uses 300 seconds by default too. There is no need to overload sssd
with requests that it would have cached.
BUG: 1215187
Change-Id: I3f04ea8cc90180d863253a9f46d62b71810a7b34
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/10371
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
For GF_CBK_CACHE_INVALIDATION, have changed the type of gfid
to be string (cannonical form) instead of opaque byte format
to ensure correctness across platforms supporting different
endianness.
BUG: 1200262
Change-Id: Iac4372714f4b4ebcd9c4393aaf46ceba3f37f587
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
Reviewed-on: http://review.gluster.org/10224
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
As suggested during the code-review of Bug1200262, have modified
GF_CBK_UPCALL to be exlusively GF_CBK_CACHE_INVALIDATION.
Thus, for any new upcall event, a new CBK procedure will be added.
Also made changes to store upcall data separately based on the
upcall event type received.
BUG: 1200262
Change-Id: I0f5e53d6f5ece16aecb514a0a426dca40fa1c755
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
Reviewed-on: http://review.gluster.org/10049
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
EEXIST and ENOENT are safe errors for geo-replication.
Since mkdir is captured in all the bricks of the changelog.
mkdir is tried multiple times as per the number of bricks.
The first one to process by gsyncd will succeed and all
others will get EEXIST. Hence EEXIST is a safe error
and can be ignored. Similarly ENOENT also in rm -rf case.
And also gsyncd validates these errors and log them in
master if it is genuine error. This is coming up with
the patch http://review.gluster.org/#/c/10048/
Hence ignoring above said safe errors.
Change-Id: I10ae86b11d49c7c3ba2be3110dace6b33daa509e
BUG: 1210562
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Reviewed-on: http://review.gluster.org/10184
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
glusterfs relies on Linux uuid implementation, which
API is incompatible with most other systems's uuid. As
a result, libglusterfs has to embed contrib/uuid,
which is the Linux implementation, on non Linux systems.
This implementation is incompatible with systtem's
built in, but the symbols have the same names.
Usually this is not a problem because when we link
with -lglusterfs, libc's symbols are trumped. However
there is a problem when a program not linked with
-lglusterfs will dlopen() glusterfs component. In
such a case, libc's uuid implementation is already
loaded in the calling program, and it will be used
instead of libglusterfs's implementation, causing
crashes.
A possible workaround is to use pre-load libglusterfs
in the calling program (using LD_PRELOAD on NetBSD for
instance), but such a mechanism is not portable, nor
is it flexible. A much better approach is to rename
libglusterfs's uuid_* functions to gf_uuid_* to avoid
any possible conflict. This is what this change attempts.
BUG: 1206587
Change-Id: I9ccd3e13afed1c7fc18508e92c7beb0f5d49f31a
Signed-off-by: Emmanuel Dreyfus <manu@netbsd.org>
Reviewed-on: http://review.gluster.org/10017
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Niels de Vos <ndevos@redhat.com>
CID: 1124447
The values of the pointer varibale checked,
before going to out label was always NULL,
hence dead code related to that is removed.
Change-Id: I0f9b84c7feb34072814557ddd023f2ae1c64ef7e
BUG: 789278
Signed-off-by: arao <arao@redhat.com>
Reviewed-on: http://review.gluster.org/9646
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
