New releases: targetcli.fb43, rtslib.fb60, configshell.fb20
by Andy Grover
Hi all,
Another release of all three, with a few small improvements to targetcli
but nothing major. The big thing is rtslib now uses pyudev instead of
parsing /sys itself, which has been a constant source of bugs for us.
NOTE: *** rtslib-fb now depends on python-udev ***
My future development plans are mainly better support for configuring
PR/ALUA. If there's some other issue or annoyance that's bugging you
please let me know and we can work to get it improved.
Thanks again to everyone who helped make this release!
Github:
https://github.com/agrover/targetcli-fb
https://github.com/agrover/rtslib-fb
https://github.com/agrover/configshell-fb
tarballs:
https://fedorahosted.org/released/targetcli-fb/
targetcli-fb 2.1.fb41:
Andy Grover <agrover(a)redhat.com> (5):
fileio completions also allow block devices
Update man page a little
HeaderDigest param should be string, not yesno
Allow WWN to be specified when creating storage objects
version 2.1.fb43
Andy Grover <andy(a)groveronline.com> (2):
Update README.md
type in README.md.
Christophe Vu-Brugier <cvubrugier(a)fastmail.fm> (2):
Document the tpg_enabled_sendtargets TPG attribute
Document the unmap_zeroes_data backstore attribute
runsisi <runsisi(a)hust.edu.cn> (1):
Fix package name for rpm spec file
rtslib-fb 2.1.fb60:
Andy Grover <agrover(a)redhat.com> (2):
Fix 'make rpm'
version 2.1.fb60
Andy Grover <andy(a)groveronline.com> (2):
Update README.md
Update README.md again
Fam Zheng <famz(a)redhat.com> (1):
UserBackedStorageObject: Fix docstring for __init__
Jon Magrini <jmagrini(a)redhat.com> (1):
[rtslib-fb] Ensure internal buffers are flushed when
saveconfig.json is written to disk.
mulhern <amulhern(a)redhat.com> (3):
Make use of pyudev package as much as possible in utils module.
Use find_parent instead of parent.
Make sure to properly avoid treating partitions the same as disk.
configshell-fb 1.1.fb20:
Andy Grover <agrover(a)redhat.com> (1):
version 1.1.fb20
Christoph Hellwig <hch(a)lst.de> (1):
configshell-fb: depend on python-six/python3-six in debian/control
Regards -- Andy
6 years, 1 month
Getting upstream targetcli-fb running on Debian 9
by Thomas Glanzmann
Hello,
I would like to use the upstream version of targetcli-fb in order to be
able to use the ALUA commands on a Debian 9 strech system. I cloned the
git repos of rtslib-fb, configshell-fb, and targetcli-fb and ran
python setup.py install
Both with python and python3. I also tried to run it inside a
virtualenv. When I start targetcli I get:
(debian) [~] targetcli
[Errno 22] Invalid argument
When I trace it it seems that 'output.write(text)' is triggering the issue. Any
ideas or instructions how to build this?
--- modulename: console, funcname: raw_write
console.py(142): output.write(text)
[Errno 22] Invalid argumentconsole.py(143): output.flush()
console.py(161): if not no_lf:
console.py(162): self.raw_write('\n', output=output)
--- modulename: console, funcname: raw_write
console.py(142): output.write(text)
console.py(143): output.flush()
targetcli(84): if not is_root:targetcli(86): sys.exit(-1) --- modulename: trace, funcname: _unsettrace
trace.py(77): sys.settrace(None)
Does someone have instructions for me to get the upstream targetcli
running on Debian 9 or can someone provide me with build instruction on
another Linux distribution where it simply works?
If you need access to a Debian 9 VM to test it by yourself, please send
me your ssh key, and I provide you access to a VM.
Cheers,
Thomas
6 years, 7 months
Re: Presenting one file backed volume Active Optimized over one tpg
and Standby over another using Debian strech
by Thomas Glanzmann
Hello,
* Thomas Glanzmann <thomas(a)glanzmann.de> [2017-08-17 20:47]:
> So what is the best way under Debian 9 strech to create a second alua group,
> set it to standby and set one of the two tpgs to the new alua group while
> removing it from the default group?
the current version of targetcli does not run on Debian 9. The fastest
way to obtain the same is to install fedora server. There is a pretty
recent version of targetcli which supports alua. In order to do the
setup the following commands need to be executed:
# create a standby alua group
cd /backstores/fileio/shared-01.v102.tuvl.de/alua/
create standby tag=1
set alua alua_access_state=2
# Assign one LUn the standby alua group:
cd /iscsi/iqn.2013-03.de.tuvl.v102.storage:shared-01.v102.tuvl.de/tpg2/luns/lun10
set alua alua_tg_pt_gp_name=standby
Afterwards it looks like that:
/> ls
o- / ......................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- block .................................................................................................. [Storage Objects: 0]
| o- fileio ................................................................................................. [Storage Objects: 1]
| | o- shared-01.v102.tuvl.de .................................... [/iscsi1/shared-01.v102.tuvl.de (10.0GiB) write-back activated]
| | o- alua ................................................................................................... [ALUA Groups: 2]
| | o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
| | o- standby ......................................................................................... [ALUA state: Standby]
| o- pscsi .................................................................................................. [Storage Objects: 0]
| o- ramdisk ................................................................................................ [Storage Objects: 0]
o- iscsi ............................................................................................................ [Targets: 1]
| o- iqn.2013-03.de.tuvl.v102.storage:shared-01.v102.tuvl.de ........................................................... [TPGs: 2]
| o- tpg1 .................................................................................................. [gen-acls, no-auth]
| | o- acls .......................................................................................................... [ACLs: 0]
| | o- luns .......................................................................................................... [LUNs: 1]
| | | o- lun10 ............................. [fileio/shared-01.v102.tuvl.de (/iscsi1/shared-01.v102.tuvl.de) (default_tg_pt_gp)]
| | o- portals .................................................................................................... [Portals: 1]
| | o- 10.102.227.143:3260 .............................................................................................. [OK]
| o- tpg2 .................................................................................................. [gen-acls, no-auth]
| o- acls .......................................................................................................... [ACLs: 0]
| o- luns .......................................................................................................... [LUNs: 1]
| | o- lun10 ...................................... [fileio/shared-01.v102.tuvl.de (/iscsi1/shared-01.v102.tuvl.de) (standby)]
| o- portals .................................................................................................... [Portals: 1]
| o- 10.102.2.0:3260 .................................................................................................. [OK]
o- loopback ......................................................................................................... [Targets: 0]
o- vhost ............................................................................................................ [Targets: 0]
The ESX server reflects the same. I found no documentation on this, is
there any?
Cheers,
Thomas
6 years, 7 months
targetcli delay shoots up as number of entries increase in a node
by Prasanna Kalever
Hi all,
I have noticed, overall creation time of a block using targetcli in
bash mode is raising linearly as the block count increase.
1st block create took ~1 sec
1000th block create taking up to 1m 45 sec
The delay is seen from targetcli command (exec in a bash mode), a
saveconfig command takes about ~ 13 sec.
Eg: when there are ~100 entries, a get global takes ~6 sec
# time targetcli get global
[...]
real 0m5.880s
user 0m4.487s
sys 0m1.389s
On an strace on "targetcli get global" noticed targetcli reads all
entries under "/sys/kerel/config/target/*", IMO which might be too
much of reading/loop over for a get global ?
More than a month before Mike(CCed) helped in analyzing this delay,
according to him on each targetcli create call rtslib will rebuild its
bs_cache, so as the /sys/kernel/config/target/core dir gets more
entries this takes longer and longer to scan.
This does not happen if we open targetcli in interactive mode and just
do multiple create commands form it, since the bs_cache is not resetup
every call.
But in our use case, scripts (written using bash mode of targetcli)
will be called when a block request polls in, so we need to operate
targetcli in bash mode.
Are there any proposed solutions for bringing down this delay ? at
least if we can cut down the delay by few sec, even that will be a
great start :-)
Myself I'm not familiar with targetcli code, but hope to read and
understand this interesting piece in the near future.
I have attached the data,
BlockCreatePlot.png: graph that shows the linear raise of delay while create
blockCreateTime.txt: data used to generate the chart
targetcliCommandDelay.txt: 'time' command output on each targetcli
command, which are used to create and export a block device
Thanks,
--
Prasanna
6 years, 7 months