If the configshell_fb package version is low, or checking the
CONFIGSHELL_VERSION fails, the create_io_timeout capability will
be disabled:
gluster-blockd[12934]: Traceback (most recent call last):
gluster-blockd[12934]: File "<string>", line 1, in <module>
gluster-blockd[12934]: ImportError: cannot import name __version__
WARNING: io timeout needs atleast configshell >=1.1.25 and tcmu-runner >= 1.5.0,
so disabling its capability [at capabilities.c+179 :<gbSetCapabilties>]
The old code will always set the io_timeout to _DEF value even
in this case when the create_io_timeout capability is disabled.
This will finally cause the gluster-block create fails even we
won't specify or care about the io-timeout option.
This fix will disable the io_timeout option as default and only
we the create_io_timeout capability is enabled will we set the
_DEF for it.
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
If we specify more than 2 volumes in one genconfig command line,
the genconfig will truncate the volumes.
Fixes: RHBZ#1787371
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Set the tcmur_cmd_time_out=43s as default, which is larger than
each IO's timeout value(default is 30s) in the client/initiator side,
and at the same time it will be larger than 42s, the Gluster ping
timeout.
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Problem:
-------
Right now, if any block volume is failed to load as part of service bringup
or node reboot, may be because of an issue from the backend, then there is
no way to reload that single block volume, we need to reload/restart all the\
block volumes present in the node just to load one block volume, this interrupts
ongoing I/O (via this path) for all the volumes hosted within the node.
Solution:
--------
Add ability to reload a single block volume without touching other block volumes
in the node.
$ gluster-block help
usage:
gluster-block [timeout <seconds>] <command> <volname[/blockname]> [<args>] [--json*]
commands:
[...]
reload <volname/blockname>
reload a block device.
[...]
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
The ringbuffer size for each target could up to the global limitation
which is 2GB, here we will allow it up to 1GB. This relevant kernel
patch has been updated into the same verions with the dynamic growth
and shrink patch set.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Previously we had code which allows passing more than HA number of hosts to the
create command. But the future was incomplete and this code was left dead.
This PR removes it all, may be once we have self-healing, this sort of feature
addition becomes more easy.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
The 'force' will only useful when resizing, so make it only optional
together with the size option.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
If we pass some unknown options, there isn't any prompt messages and
it will continue and successes, like:
IQN: iqn.2016-12.org.gluster-block:d27f0da6-ccde-4479-bfd6-a6e9eb9790f1
PORTAL(S): 192.168.195.162:3260
RESULT: SUCCESS
It should fail the command.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
This will still need to depend the taregetcli's saveconfig support,
the rtslib PR is open-iscsi/rtslib-fb#150.
When creating the BV with the 'block-size <SIZE>' option:
In case all the ha nodes have supported the rtslib-fb#150:
1) if local node support the block-size, but if there is any of
the remote nodes is not, it will fail with the cap not match error.
2) if local node does not support the block-size, no matter whether
the remote nodes support it or not, it will always ignore the
block-size option due to the exist bug.
In case if there is any of the ha nodes does not support rtslib-fb#150:
3) if local node support the block-size, it will always fails with the
cap not match error.
4) if local mode does not support the block-size, no matter whether
the remote nodes support it or not, it will ignore the block-size
option due to the exist bug.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
We have noticed that our users are trying to create block volume with
hostnames and reporting issues, so it would be better if we defend it.
$ gluster-block create sample-test/block block.lab.green.com 1MiB
hostnames are not supported with gluster-block
Hint: please use ip addresses only
$ gluster-block create sample-test/block 192.168.43.158 1MiB
IQN: iqn.2016-12.org.gluster-block:2d4a2dfb-db5d-401c-b21a-01c57ad38705
PORTAL(S): 192.168.43.158:3260
RESULT: SUCCESS
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Problems:
-------
Since we have make the cli and server routines into 2 different
processes in gluster-blockd daemon, the gbConf data will also
be have different copies. If the gbConf data is changed by the
dyn-config thread in the cli(parent) process, the new changes won't
be visible for the server(child) process.
Resolution:
----------
For the gbConf data, use the shared memory instead of the in the
data segment.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Problem:
-------
There has tons of warnings when building the rpms:
../utils/utils.h:166:25: warning: comparison with string literal results in unspecified behavior [-Waddress]
if ((str) == "mgmt") \
^
gluster-block.c:463:3: warning: (near initialization for 'mobj.block_name') [-Wmissing-braces]
gluster-block.c:464:3: warning: missing braces around initializer [-Wmissing-braces]
blockModifySizeCli msobj = {0, };
^
block_svc_routines.c: In function 'block_delete_cli_1_svc_st':
block_svc_routines.c:4707:37: warning: ?: using integer constants in boolean context [-Wint-in-bool-context]
LOG("cmdlog", errCode?GB_LOG_ERROR:GB_LOG_INFO, "%s", reply->out);
../utils/utils.h:169:17: note: in definition of macro 'LOG'
if (level <= gbConf.logLevel) { \
^~~~~
Resolution:
----------
Use the strcmp() instead and add extra braces when initializing.
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
If there is no any variable argument in the logger callout, it
will hit the following compile errors:
../utils/utils.h:175:34: error: expected expression before ‘,’ token
__VA_ARGS__, __FILE__, __LINE__, __FUNCTION__); \
^
gluster-blockd.c:268:5: note: in expansion of macro ‘LOG’
LOG ("mgmt", GB_LOG_ERROR, "Test................");
^
More detail please see the GNU doc:
https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Creating the socket is not needed for svcunix_create(), it does all the
work for us (and prevents "address already in use" errors).
For svctcp_create(), the socket is expected on port 24010 and hence
needs to be setup completely with bind() and listen() before it can be
used. Registering the RPC-program should make it possible to use a
dynamically assigned port, but the gluster-block CLI expects it on the
static port.
This also fixes a warning when building the RPM from 'make dist' tarball
as the 22 June 2017 was a Thursday, nt Tuesday.
Changes from pkalever:
Add a flag at config time for tweaking the use of tirpc or glibc sunrpc
$ ./autogen.sh && ./configure --enable-tirpc=yes/no
Change-Id: If3a6b7527399dd0a5a16f4273efdd607617289de
Updates: #56
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
glibc has removed the rpc functions from current releases. Instead of
relying on glibc providing these, the modern libtirpc library should be
used instead.
Change-Id: I46c979e52147abce956255de5ad16b01b5621f52
Updates: #56
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Problem:
-------
Currently cli process Loads Config on every operation in cli process
context. Hence log msgs:
DEBUG: logLevel now is TRACE [at utils.c+50:<glusterBlockSetLogLevel>]
DEBUG: glfsLruCount now is 5 [at lru.c+43:<glusterBlockSetLruCount>]
are dumped to gluster-blockd.log on every single cli operation. Apart
from the inotify triggers to Load Config.
Solution:
--------
Print the Key:Value config file parameters to respective log files based
on the process context.
That is,
- if cli process calls Load Config, then dump the logs to
gluster-block-cli.log (only DEBUG or higher level)
- if dameon process calls Load Config ( via DynConfig thread), then dump
the logs to gluster-blockd.log (in CRIT level)
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Tested-by: Xiubo Li <xiubli@redhat.com>
As of now prealloc is off by default.
This patch change the default prealloc to full.
Fixes: #149
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
gluster-block (0.3)
usage:
gluster-block [timeout <seconds>] <command> <volname[/blockname]> [<args>] [--json*]
commands:
[...]
common cli options: (fixed formats)
timeout <seconds>
it is the time in seconds that cli can wait for daemon to respond.
[default: timeout 300]
--json*
used to request the output result in json format [default: plain text]
supported JSON formats: --json|--json-plain|--json-spaced|--json-pretty
Precedence of various methods to set cli timeout:
1. Options set through config file /etc/sysconfig/gluster-blockd [Top Prio]
eg: uncommenting and adjusting key:value at /etc/sysconfig/gluster-blockd
2. Argument passed at cli
eg: timeout 900
3. Environment variable
eg: export GB_CLI_TIMEOUT=900
4. Code level defaults (300 sec) [Least Prio]
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed & Tested-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
There are two rpc calls involved in the design,
Channel A: From cli process to local daemon (cli thread)
Channel B: From local daemon (cli thread) to remote daemon (remote thread)
Timeout for channel A is configurable now, using
/etc/sysconfig/gluster-blockd, by adjusting option 'GB_CLI_TIMEOUT' (in seconds)
$ cat /etc/sysconfig/gluster-blockd
GB_CLI_TIMEOUT=900
Changes to this value takes effect every time we start running/triggering new
cli command/request.
At the moment making Timeout configurable for channel B is not important, it is
hardcoded as 300 seconds in the code for now.
Some more details:
-----------------
It would have been an easy fix calling clnt_control() right after clnt_create(),
unfortunately there is a bug in glibc, which is why we had to hack the rpc
generated code instead of directly calling clnt_control(), see my very old
commit [1] which explains why we had to override (in a hacky-way) the default
generated TIMEOUT.
[1] 1dbbd7d457
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed & Tested-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Amar Tumballi <amarts@redhat.com>
Record the responses of all the requests for the operations
Create/Delete/Modify/Replace on gluster-block.
The logging format is:
In case of success:
[time] INFO: <command string> <function details>
[time] INFO: Response string <function details>
In case of failure:
[time] INFO: <command string> <function details>
[time] ERROR: Response string <function details>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Bhumika Goyal <bgoyal@redhat.com>
With the introduction of new option 'storage' for the create command,
the field 'size' is rendered optional when that 'storage' option is given.
Update the man page and help commands to reflect this change.
Signed-off-by: Bhumika Goyal <bgoyal@redhat.com>
Reviewed-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
From man:
clnt_destroy(CLIENT *clnt);
A macro that destroys the client's RPC handle. Destruction usually involves
deallocation of private data structures, including clnt itself. Use of
clnt is undefined after calling clnt_destroy(). If the RPC library opened the
associated socket, it will close it also. Otherwise, the socket remains open.
we are closing the socket twice in this case,
i.e. by calling clnt_destroy and then close(sockfd)
Thanks to Pranith for the RC.
Tested-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Pranith Kumar K <pkarampu@redhat.com>
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
also other minor compiler errors
Change-Id: I17625008d91740f3ba9efc6e574ec3dcd0b6c85f
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
From,
$ targetcli /backstores/user:glfs/block get attribute
ATTRIBUTE CONFIG GROUP
======================
hw_block_size=512 [ro]
----------------------
Hence making the min acceptable size to be 1 sector/block i.e. 512 bytes
This patch also, explicitly mention in docs about bytes as default size units.
Change-Id: Iec8797082d02cc9ad51fc17e11f2ba3073aaeda0
Fixes: #35
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
blockResponse *
block_delete_1(blockDelete *argp, CLIENT *clnt)
{
static blockResponse clnt_res; <<<<<<-------- Same memory is used by everyone
memset((char *)&clnt_res, 0, sizeof(clnt_res)); <<<<<---- Here memset is happening
if (clnt_call (clnt, BLOCK_DELETE,
(xdrproc_t) xdr_blockDelete, (caddr_t) argp,
(xdrproc_t) xdr_blockResponse, (caddr_t) &clnt_res,
TIMEOUT) != RPC_SUCCESS) {
return (NULL);
}
return (&clnt_res); <<<<<---- ptr to this memory is returned.
}
So while Thread-1 is returned "return (&clnt_res);" another thread could be
doing "memset((char *)&clnt_res, 0, sizeof(clnt_res));"
This seem to be a day-1 gluster-blockd bug from the looks of it.
Change-Id: I3fc76d7814c4fe5b286577586ec44d752dcc73f0
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Currently the default logdir is DATADIR /log/gluster-block/
This patch will provide a way to change this default logdir via Env variable
$ export GB_LOGDIR=/var/log/gluster-block-new-path/
Note: make sure to restart the processes (cli & daemon) after you set GB_LOGDIR
Change-Id: Id142e4a4dfe7b6ebc9cf8296b8ceb8bff37691b8
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
