My name is Zac Dover and I was hired by Sage to improve the Ceph
documentation.
For the past few months, I have been reading the documentation that exists
and making bugfixes where I am able. Now I think it's time to ask the
general Ceph community for complaints about and request for improvements to
the documentation.
There is a general documentation meeting called the "DocuBetter Meeting",
and it is held every two weeks. The next DocuBetter Meeting will be on
February 26, 2020 at 6 PM PST, and will run for thirty minutes. Everyone
with a documentation-related request or complaint is invited. The meeting
will be held here: https://bluejeans.com/908675367
<https://www.google.com/url?q=https://bluejeans.com/908675367&sa=D&usd=2&usg…>
Send documentation-related requests and complaints to me by replying to
this email and CCing me at zac.dover(a)gmail.com.
This message will be sent to dev(a)ceph.io every Monday morning, North
American time.
Zac Dover
I read NVMEDevice.cc code. However, one thing I am not quite sure of why
aio_submit is waiting for all IO finished before it returns. This implies
that any AIO thread does the IO in sync mode.
Looking at the following code path:
aio_submit -> _aio_handle, inside _aio_handle, the code loop and wait if
num_running > 0.
Is my reading correct? Is this intentional? If so, why?
Appreciate if someone can help me understand this.
--
-Howard
Hi Cephers,
Is there an easy way to dump a BlueStore internal variable, to be specific, a vector (the vector contains some debugging data), from linux command line?
The closed thing I can think of is to modify the perf_counters to do that. I’m wondering is there any easy way to do that?
I also tried to add the dump function in the BlueStore destructor, but the destructor is always called when the vstart is
invoked, and stop.sh script doesn’t call the destructor.
Please advice.
Thanks,
Yiming
Hi all,
I have been using Ceph now since some days. I started reading about it
briefly and then deployed the Ceph storage cluster. But I would really like
to dive deeper into it.
I am particularly interested in understanding the* librados* and *CRUSH*
algorithm. I have a question. Can some of you please share some research
literature (if any) regarding implementing *Librados* and *CRUSH* on
hardware devices like ASIC or FPGA.
Thanks
Below is the current queue of PRs:
https://github.com/ceph/ceph/pulls?page=2&q=is%3Aopen+label%3Anautilus-batc…
Most PRs are being tested.
Unless there are objections, we will start QE validation as soon as
all PRs in this queue were merged.
Dev leads - pls add and tag all RRs that must be included.
Thx
YuriW
I'm happy to announce the very first formal release of the go-ceph API
bindings.
https://github.com/ceph/go-ceph/releases/tag/v0.2.0
They aim to play a similar role to the "pybind" python bindings in the ceph
tree but for the Go language. These API bindings require the use of cgo.
There are already a few consumers of this library in the wild and the
ceph-csi project has plans to make use of this library.
Specific questions, comments, bugs etc are best directed at our github issues
tracker.
PS. I was directed here to make this announcement. If this is not the
appropriate venue or is considered too spammy please let me know off list.
Thanks!
---
John Mulligan
phlogistonjohn(a)asynchrono.us
jmulligan(a)redhat.com
Hi,
Ever since last Sunday some of my tests in Jenkins are driving me nuts.
In some odd way some of the program output contains more space at
certain places. Which then fails in cram/tox/unit tests.
But I cannot seem to be able to tackle the origin of this problem.
First is suspected a new version of prettytable, but it also occurs in
unittest_texttable.
Anybody suggestions where to start looking?
Perhaps you have an idea which I have not thought off?
Thanx,
--WjW
example:
4/5 Test #53: unittest_texttable ...............***Failed 0.12 sec
Running main() from gmock_main.cc
[==========] Running 4 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 4 tests from TextTable
[ RUN ] TextTable.Alignment
/home/jenkins/workspace/ceph-master/src/test/test_texttable.cc:32: Failure
Expected equality of these values:
"HEAD1 HEAD2 HEAD3 \n1 2 3 \n"
oss.str().c_str()
Which is: "HEAD1 HEAD2 HEAD3 \n1 2 3 \n"
With diff:
@@ -1,2 +1,2 @@
-HEAD1 HEAD2 HEAD3
-1 2 3 \n
+HEAD1 HEAD2 HEAD3
+1 2 3 \n
[ FAILED ] TextTable.Alignment (1 ms)
[ RUN ] TextTable.WidenAndClearShrink
/home/jenkins/workspace/ceph-master/src/test/test_texttable.cc:46: Failure
Expected equality of these values:
"1 \nwider \n"
oss.str().c_str()
Which is: "1 \nwider \n"
With diff:
@@ -1,2 +1,2 @@
-1
-wider \n
+1
+wider \n
[ FAILED ] TextTable.WidenAndClearShrink (0 ms)
[ RUN ] TextTable.Indent
/home/jenkins/workspace/ceph-master/src/test/test_texttable.cc:64: Failure
Expected equality of these values:
" 1 \n s \n"
oss.str().c_str()
Which is: " 1 \n s \n"
With diff:
@@ -1,2 +1,2 @@
- 1
- s \n
+ 1
+ s \n
[ FAILED ] TextTable.Indent (0 ms)
[ RUN ] TextTable.TooManyItems
warning: unable to setrlimit(): (1) Operation not permitted
[ OK ] TextTable.TooManyItems (36 ms)
[----------] 4 tests from TextTable (37 ms total)
[----------] Global test environment tear-down
[==========] 4 tests from 1 test suite ran. (37 ms total)
[ PASSED ] 1 test.
[ FAILED ] 3 tests, listed below:
[ FAILED ] TextTable.Alignment
[ FAILED ] TextTable.WidenAndClearShrink
[ FAILED ] TextTable.Indent
3 FAILED TESTS
Hi All,
I recently experienced an issue while trying to use FIO on Ceph(master branch). When Ceph is started,
the mon host is something like [v2:128.XXX.XXX.XXX:12345, v1:128.XXX.XXX.XXX:12346]
if I try to use the FIO now, the “addr cannot be parsed” error will occur.
Then I change the mon host to 128.XXX.XXX.XXX:12345, ceph will also show a connection error too.
I checked the IP and port, which are used correctly.
RBD bench works fine, only FIO has this issue.
Please advice.
Thanks,
Yiming
I am trying to test the DPDK feature. However, I didn't find a document on
how to do it. Can someone give me instructions? I suppose DPDK is also
supported by MDS daemon as well, right?
--
-Howard
