Re: FreeBSD Building and Testing
On 6-1-2016 08:51, Mykola Golub wrote:
On Mon, Dec 28, 2015 at 05:53:04PM +0100, Willem Jan Withagen wrote:
Hi,
Can somebody try to help me and explain why
in test: Func: test/mon/osd-crash
Func: TEST_crush_reject_empty started
Fails with a python error which sort of startles me:
test/mon/osd-crush.sh:227: TEST_crush_reject_empty: local
empty_map=testdir/osd-crush/empty_map
test/mon/osd-crush.sh:228: TEST_crush_reject_empty: :
test/mon/osd-crush.sh:229: TEST_crush_reject_empty: ./crushtool -c
testdir/osd-crush/empty_map.txt -o testdir/osd-crush/empty_map.m
ap
test/mon/osd-crush.sh:230: TEST_crush_reject_empty: expect_failure
testdir/osd-crush 'Error EINVAL' ./ceph osd setcrushmap -i testd
ir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1171: expect_failure: local
dir=testdir/osd-crush
../qa/workunits/ceph-helpers.sh:1172: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1173: expect_failure: local 'expected=Error
EINVAL'
../qa/workunits/ceph-helpers.sh:1174: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1175: expect_failure: local success
../qa/workunits/ceph-helpers.sh:1176: expect_failure: pwd
../qa/workunits/ceph-helpers.sh:1177: expect_failure: printenv
../qa/workunits/ceph-helpers.sh:1178: expect_failure: echo ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1180: expect_failure: ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
*** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH ***
Traceback (most recent call last):
File "./ceph", line 936, in
retval = main()
File "./ceph", line 874, in main
sigdict, inbuf, verbose)
File "./ceph", line 457, in new_style_command
inbuf=inbuf)
File "/usr/srcs/Ceph/wip-freebsd-wjw/ceph/src/pybind/ceph_argparse.py",
line 1208, in json_command
raise RuntimeError('"{0}": exception {1}'.format(argdict, e))
RuntimeError: "{'prefix': u'osd setcrushmap'}": exception "['{"prefix": "osd
setcrushmap"}']": exception 'utf8' codec can't decode b
yte 0x86 in position 56: invalid start byte
Which is certainly not the type of error expected.
But it is hard to detect any 0x86 in the arguments.
Are you able to reproduce this problem manually? I.e. in src dir, start the
cluster using vstart.sh:
./vstart.sh -n
Check it is running:
./ceph -s
Repeat the test:
truncate -s 0 empty_map.txt
./crushtool -c empty_map.txt -o empty_map.map
./ceph osd setcrushmap -i empty_map.map
Expected output:
"Error EINVAL: Failed crushmap test: ./crushtool: exit status: 1"
Hi all,
I've spent the Xmas days trying to learn more about Python.
(And catching up with old friends :) )
My heritage is the days of assembler, shell script, C, Perl and likes.
So the pony had to learn a few new tricks. (aka language)
I'm now trying to get python nosetest to actually work
In the mean time I also found that FreeBSD has patches for Googletest
to actually make most of the DEATH tests work.
I think this python stream pars error got resolved by upgrading
everything build, including the complete package environment and
upgrading kernel and tools... :) Which I think cleaned out the python
environment which was a bit mixed up with different versions.
Now test/mon/osd-crush.sh return OKE, so I guess the setup of the
environment
is relatively critical.
I also noted that some of the test get more tests done IF I run them under
root-priviledges
The last test run resulted in:
=
ceph 10.0.1: src/test-suite.log
=
# TOTAL: 120
# PASS: 110
# SKIP: 0
# XFAIL: 0
# FAIL: 10
# XPASS: 0
# ERROR: 0
FAIL ceph-detect-init/run-tox.sh (exit status: 1)
FAIL test/run-rbd-unit-tests.sh (exit status: 138)
FAIL test/ceph_objectstore_tool.py (exit status: 1)
FAIL test/cephtool-test-mon.sh (exit status: 1)
FAIL test/cephtool-test-rados.sh (exit status: 1)
FAIL test/libradosstriper/rados-striper.sh (exit status: 1)
FAIL test/test_objectstore_memstore.sh (exit status: 127)
FAIL test/ceph-disk.sh (exit status: 1)
FAIL test/pybind/test_ceph_argparse.py (exit status: 127)
FAIL test/pybind/test_ceph_daemon.py (exit status: 127)
where the first and last 2 actually don't work because of python things
that are not working on FreeBSD and I have to sort out.
ceph_detect_init.exc.UnsupportedPlatform: Platform is not supported.:
../test-driver: ./test/pybind/test_ceph_argparse.py: not found
FAIL test/pybind/test_ceph_argparse.py (exit status: 127)
I also have:
./test/test_objectstore_memstore.sh: ./ceph_test_objectstore: not found
FAIL test/test_objectstore_memstore.sh (exit status: 127)
Which ia a weird one, that needs some TLC.
So I'm slowly getting there...
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD Building and Testing
On 5-1-2016 19:23, Gregory Farnum wrote:
On Mon, Dec 28, 2015 at 8:53 AM, Willem Jan Withagen <w...@digiware.nl> wrote:
Hi,
Can somebody try to help me and explain why
in test: Func: test/mon/osd-crash
Func: TEST_crush_reject_empty started
Fails with a python error which sort of startles me:
test/mon/osd-crush.sh:227: TEST_crush_reject_empty: local
empty_map=testdir/osd-crush/empty_map
test/mon/osd-crush.sh:228: TEST_crush_reject_empty: :
test/mon/osd-crush.sh:229: TEST_crush_reject_empty: ./crushtool -c
testdir/osd-crush/empty_map.txt -o testdir/osd-crush/empty_map.m
ap
test/mon/osd-crush.sh:230: TEST_crush_reject_empty: expect_failure
testdir/osd-crush 'Error EINVAL' ./ceph osd setcrushmap -i testd
ir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1171: expect_failure: local
dir=testdir/osd-crush
../qa/workunits/ceph-helpers.sh:1172: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1173: expect_failure: local 'expected=Error
EINVAL'
../qa/workunits/ceph-helpers.sh:1174: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1175: expect_failure: local success
../qa/workunits/ceph-helpers.sh:1176: expect_failure: pwd
../qa/workunits/ceph-helpers.sh:1177: expect_failure: printenv
../qa/workunits/ceph-helpers.sh:1178: expect_failure: echo ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1180: expect_failure: ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
*** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH ***
Traceback (most recent call last):
File "./ceph", line 936, in
retval = main()
File "./ceph", line 874, in main
sigdict, inbuf, verbose)
File "./ceph", line 457, in new_style_command
inbuf=inbuf)
File "/usr/srcs/Ceph/wip-freebsd-wjw/ceph/src/pybind/ceph_argparse.py",
line 1208, in json_command
raise RuntimeError('"{0}": exception {1}'.format(argdict, e))
RuntimeError: "{'prefix': u'osd setcrushmap'}": exception "['{"prefix": "osd
setcrushmap"}']": exception 'utf8' codec can't decode b
yte 0x86 in position 56: invalid start byte
Which is certainly not the type of error expected.
But it is hard to detect any 0x86 in the arguments.
And yes python is right, there are no UTF8 sequences that start with 0x86.
Question is:
Why does it want to parse with UTF8?
And how do I switch it off?
Or how to I fix this error?
I've not handled this myself but we've seen this a few times. The
latest example in a quick email search was
http://tracker.ceph.com/issues/9405, and it was apparently having a
string which wasn't null-terminated.
Looks like in my case it was due to too large a mess in the python
environment.
But I'll keep this in my mind, IFF it comes back to haunt me more.
Thanx,
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD Building and Testing
On 6-1-2016 08:51, Mykola Golub wrote: > > Are you able to reproduce this problem manually? I.e. in src dir, start the > cluster using vstart.sh: > > ./vstart.sh -n > > Check it is running: > > ./ceph -s > > Repeat the test: > > truncate -s 0 empty_map.txt > ./crushtool -c empty_map.txt -o empty_map.map > ./ceph osd setcrushmap -i empty_map.map > > Expected output: > > "Error EINVAL: Failed crushmap test: ./crushtool: exit status: 1" > Oke thanx Nice to have some of these examples... --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD Building and Testing
Hi,
Can somebody try to help me and explain why
in test: Func: test/mon/osd-crash
Func: TEST_crush_reject_empty started
Fails with a python error which sort of startles me:
test/mon/osd-crush.sh:227: TEST_crush_reject_empty: local
empty_map=testdir/osd-crush/empty_map
test/mon/osd-crush.sh:228: TEST_crush_reject_empty: :
test/mon/osd-crush.sh:229: TEST_crush_reject_empty: ./crushtool -c
testdir/osd-crush/empty_map.txt -o testdir/osd-crush/empty_map.m
ap
test/mon/osd-crush.sh:230: TEST_crush_reject_empty: expect_failure
testdir/osd-crush 'Error EINVAL' ./ceph osd setcrushmap -i testd
ir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1171: expect_failure: local
dir=testdir/osd-crush
../qa/workunits/ceph-helpers.sh:1172: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1173: expect_failure: local
'expected=Error EINVAL'
../qa/workunits/ceph-helpers.sh:1174: expect_failure: shift
../qa/workunits/ceph-helpers.sh:1175: expect_failure: local success
../qa/workunits/ceph-helpers.sh:1176: expect_failure: pwd
../qa/workunits/ceph-helpers.sh:1177: expect_failure: printenv
../qa/workunits/ceph-helpers.sh:1178: expect_failure: echo ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
../qa/workunits/ceph-helpers.sh:1180: expect_failure: ./ceph osd
setcrushmap -i testdir/osd-crush/empty_map.map
*** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH ***
Traceback (most recent call last):
File "./ceph", line 936, in
retval = main()
File "./ceph", line 874, in main
sigdict, inbuf, verbose)
File "./ceph", line 457, in new_style_command
inbuf=inbuf)
File
"/usr/srcs/Ceph/wip-freebsd-wjw/ceph/src/pybind/ceph_argparse.py", line
1208, in json_command
raise RuntimeError('"{0}": exception {1}'.format(argdict, e))
RuntimeError: "{'prefix': u'osd setcrushmap'}": exception "['{"prefix":
"osd setcrushmap"}']": exception 'utf8' codec can't decode b
yte 0x86 in position 56: invalid start byte
Which is certainly not the type of error expected.
But it is hard to detect any 0x86 in the arguments.
And yes python is right, there are no UTF8 sequences that start with 0x86.
Question is:
Why does it want to parse with UTF8?
And how do I switch it off?
Or how to I fix this error?
Thanx,
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD Building and Testing
On 21-12-2015 01:45, Xinze Chi (信泽) wrote:
sorry for delay reply. Please have a try
https://github.com/ceph/ceph/commit/ae4a8162eacb606a7f65259c6ac236e144bfef0a.
Tried this one first:
Testsuite summary for ceph 10.0.1
# TOTAL: 120
# PASS: 100
# SKIP: 0
# XFAIL: 0
# FAIL: 20
# XPASS: 0
# ERROR: 0
So that certainly helps.
Have not yet analyzed the log files... But is seems we are getting
somewhere.
Needed to manually kill a rados access in:
| | | \-+- 09792 wjw /bin/sh ../test-driver
./test/ceph_objectstore_tool.py
| | | \-+- 09807 wjw python
./test/ceph_objectstore_tool.py (python2.7)
| | | \--- 11406 wjw
/usr/srcs/Ceph/wip-freebsd-wjw/ceph/src/.libs/rados -p rep_pool -N put
REPobject1 /tmp/data.9807/-REPobject1__head
But also 2 mon-osd's were running, and perhaps ine was nog belonging
with that test. So they could be in each others way.
Found some fails in OSD's at:
./test-suite.log:osd/ECBackend.cc: 201: FAILED assert(res.errors.empty())
./test-suite.log:osd/ECBackend.cc: 201: FAILED assert(res.errors.empty())
struct OnRecoveryReadComplete :
public GenContext<pair<RecoveryMessages*, ECBackend::read_result_t& >
&> {
ECBackend *pg;
hobject_t hoid;
set want;
OnRecoveryReadComplete(ECBackend *pg, const hobject_t )
: pg(pg), hoid(hoid) {}
void finish(pair ) {
ECBackend::read_result_t = in.second;
// FIXME???
assert(res.r == 0);
201:assert(res.errors.empty());
assert(res.returned.size() == 1);
pg->handle_recovery_read_complete(
hoid,
res.returned.back(),
res.attrs,
in.first);
}
};
Given the FIXME?? the code here could be fishy??
I would say that just this patch would be sufficient.
The second patch also looks like it is could be useful since it
lowers the bar on being tested. And when just aligning is required
because of (a)iovec processing that 4096 will likely suffice.
Thanx you very much for the help.
--WjW
2015-12-21 0:10 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
Hi,
Most of the Ceph is getting there in the most crude and rough state.
So beneath is a status update on what is not working for me jet.
Especially help with the aligment problem in os/FileJournal.cc would be
appricated... It would allow me to run ceph-osd and run more tests to
completion.
What would happen if I comment out this test, and ignore the fact that
thing might be unaligned?
Is it a performance/paging issue?
Or is data going to be corrupted?
--WjW
PASS: src/test/run-cli-tests
Testsuite summary for ceph 10.0.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
gmake test:
Testsuite summary for ceph 10.0.0
# TOTAL: 119
# PASS: 95
# SKIP: 0
# XFAIL: 0
# FAIL: 24
# XPASS: 0
# ERROR: 0
The folowing notes can be made with this:
1) the run-cli-tests run to completion because I excluded the RBD tests
2) gmake test has the following tests FAIL:
FAIL: unittest_erasure_code_plugin
FAIL: ceph-detect-init/run-tox.sh
FAIL: test/erasure-code/test-erasure-code.sh
FAIL: test/erasure-code/test-erasure-eio.sh
FAIL: test/run-rbd-unit-tests.sh
FAIL: test/ceph_objectstore_tool.py
FAIL: test/test-ceph-helpers.sh
FAIL: test/cephtool-test-osd.sh
FAIL: test/cephtool-test-mon.sh
FAIL: test/cephtool-test-mds.sh
FAIL: test/cephtool-test-rados.sh
FAIL: test/mon/osd-crush.sh
FAIL: test/osd/osd-scrub-repair.sh
FAIL: test/osd/osd-scrub-snaps.sh
FAIL: test/osd/osd-config.sh
FAIL: test/osd/osd-bench.sh
FAIL: test/osd/osd-reactivate.sh
FAIL: test/osd/osd-copy-from.sh
FAIL: test/libradosstriper/rados-striper.sh
FAIL: test/test_objectstore_memstore.sh
FAIL: test/ceph-disk.sh
FAIL: test/pybind/test_ceph_argparse.py
FAIL: test/pybind/test_ceph_daemon.py
FAIL: ../qa/workunits/erasure-code/encode-decode-non-regression.sh
Most of the fails are because ceph-osd crashed consistently on:
-1 journal bl.is_aligned(block_size) 0
bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE) 1
-1 journal block_size 131072 CEPH_MINIMUM_BLOCK_SIZE 4096
CEPH_PAGE_SIZE 4096 header.alignment 131072
bl buffer::list(len=131072, buffer::ptr(0~131072 0x805319000 in raw
0x805319000 len 131072 nref 1))
os/FileJournal.cc: In function 'void FileJournal::align_bl(off64_t,
bufferlist &)' thread 805217400 t
Re: FreeBSD Building and Testing
On 20-12-2015 17:10, Willem Jan Withagen wrote:
Hi,
Most of the Ceph is getting there in the most crude and rough state.
So beneath is a status update on what is not working for me jet.
Further:
A) unittest_erasure_code_plugin failes on the fact that there is a
different error code returned when dlopen-ing a non existent library.
load dlopen(.libs/libec_invalid.so): Cannot open
".libs/libec_invalid.so"load dlsym(.libs/libec_missing_version.so, _
_erasure_code_init): Undefined symbol
"__erasure_code_init"test/erasure-code/TestErasureCodePlugin.cc:88: Failure
Value of: instance.factory("missing_version", g_conf->erasure_code_dir,
profile, _code, )
Actual: -2
Expected: -18
EXDEV is actually 18, so that part is correct.
But EXDEV is cross-device link error.
Where as the actual answer: -2 is factual correct:
#define ENOENT 2 /* No such file or directory */
So why is the test for EXDEV instead of ENOENT?
Could be a typical Linux <> FreeBSD thingy.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
FreeBSD Building and Testing
Hi,
Most of the Ceph is getting there in the most crude and rough state.
So beneath is a status update on what is not working for me jet.
Especially help with the aligment problem in os/FileJournal.cc would be
appricated... It would allow me to run ceph-osd and run more tests to
completion.
What would happen if I comment out this test, and ignore the fact that
thing might be unaligned?
Is it a performance/paging issue?
Or is data going to be corrupted?
--WjW
PASS: src/test/run-cli-tests
Testsuite summary for ceph 10.0.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
gmake test:
Testsuite summary for ceph 10.0.0
# TOTAL: 119
# PASS: 95
# SKIP: 0
# XFAIL: 0
# FAIL: 24
# XPASS: 0
# ERROR: 0
The folowing notes can be made with this:
1) the run-cli-tests run to completion because I excluded the RBD tests
2) gmake test has the following tests FAIL:
FAIL: unittest_erasure_code_plugin
FAIL: ceph-detect-init/run-tox.sh
FAIL: test/erasure-code/test-erasure-code.sh
FAIL: test/erasure-code/test-erasure-eio.sh
FAIL: test/run-rbd-unit-tests.sh
FAIL: test/ceph_objectstore_tool.py
FAIL: test/test-ceph-helpers.sh
FAIL: test/cephtool-test-osd.sh
FAIL: test/cephtool-test-mon.sh
FAIL: test/cephtool-test-mds.sh
FAIL: test/cephtool-test-rados.sh
FAIL: test/mon/osd-crush.sh
FAIL: test/osd/osd-scrub-repair.sh
FAIL: test/osd/osd-scrub-snaps.sh
FAIL: test/osd/osd-config.sh
FAIL: test/osd/osd-bench.sh
FAIL: test/osd/osd-reactivate.sh
FAIL: test/osd/osd-copy-from.sh
FAIL: test/libradosstriper/rados-striper.sh
FAIL: test/test_objectstore_memstore.sh
FAIL: test/ceph-disk.sh
FAIL: test/pybind/test_ceph_argparse.py
FAIL: test/pybind/test_ceph_daemon.py
FAIL: ../qa/workunits/erasure-code/encode-decode-non-regression.sh
Most of the fails are because ceph-osd crashed consistently on:
-1 journal bl.is_aligned(block_size) 0
bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE) 1
-1 journal block_size 131072 CEPH_MINIMUM_BLOCK_SIZE 4096
CEPH_PAGE_SIZE 4096 header.alignment 131072
bl buffer::list(len=131072, buffer::ptr(0~131072 0x805319000 in raw
0x805319000 len 131072 nref 1))
os/FileJournal.cc: In function 'void FileJournal::align_bl(off64_t,
bufferlist &)' thread 805217400 time 2015-12-19 13:43:06.706797
os/FileJournal.cc: 1045: FAILED assert(0 == "bl should be align")
This is bugging me already for a few days, but I haven't found an easy
way to debug this, run it in gdb while being live or in post-mortum.
Further:
A) unittest_erasure_code_plugin failes on the fact that there is a
different error code returned when dlopen-ing a non existent library.
load dlopen(.libs/libec_invalid.so): Cannot open
".libs/libec_invalid.so"load dlsym(.libs/libec_missing_version.so, _
_erasure_code_init): Undefined symbol
"__erasure_code_init"test/erasure-code/TestErasureCodePlugin.cc:88: Failure
Value of: instance.factory("missing_version", g_conf->erasure_code_dir,
profile, _code, )
Actual: -2
Expected: -18
load dlsym(.libs/libec_missing_entry_point.so, __erasure_code_init):
Undefined symbol "__erasure_code_init"erasure_co
de_init(fail_to_initialize,.libs): (3) No such processload
__erasure_code_init()did not register fail_to_registerload
: example erasure_code_init(example,.libs): (17) File existsload:
example [ FAILED ] ErasureCodePluginRegistryTest.
all (330 ms)
B) ceph-detect-init/run-tox.sh failes on the fact that I need to work in
FreeBSD in the tests.
C) ./gtest/include/gtest/internal/gtest-port.h:1358:: Condition
has_owner_ && pthread_equal(owner_, pthread_se
lf()) failed. The current thread is not holding the mutex @0x161ef20
./test/run-rbd-unit-tests.sh: line 9: 78053 Abort trap
(core dumped) unittest_librbd
Which I think I found some commit comments about in either trac or git
about FreeBSD not being able to do things to its own thread. Got to look
into this.
D) Fix some of the other python code to work as expected.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD is receiving traps on os/FileJournal.cc:1036
On 16-12-2015 13:51, Xinze Chi (信泽) wrote:
> Would you mind create an issue in http://tracker.ceph.com/ and tell me
> how to reproduce the bug?
http://tracker.ceph.com/issues/14095
Not sure if the description is enough to actually to reproduce the assert.
--WjW
>
> Thanks.
>
> 2015-12-16 18:26 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
>> On 16-12-2015 10:40, Xinze Chi (信泽) wrote:
>>>
>>> Because we use the new strategy for filejournal in master branch. the
>>> write entry submit to writeq is aligned already.
>>> So if assert at this line, this strategy should have bug.
>>>
>>> I do not know why you have some heads #include, Maybe you modify the
>>> logic in filejournal?
>>
>>
>> No, the adds I've done are to work around the fact that the linux_version
>> stuff
>> is not really going to work for FreeBSD. Not the test, nor the resulting
>> code.
>>
>> So the header part of the file now looks like:
>> #include "common/blkdev.h"
>> #if defined(__linux__)
>> #include "common/linux_version.h"
>> #endif
>>
>> #if defined(__FreeBSD__)
>> #include "common/freebsd_version.h"
>> #define O_DSYNC O_SYNC
>> #endif
>>
>> The remainder of the diffs are about locking when using aio, which i do not
>> ATM.
>>
>> So never say never with software, but I think I've left the logic as it
>> is/was.
>>
>> --WjW
>>
>>
>>>
>>> 2015-12-16 17:20 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
>>>>
>>>> On 16-12-2015 02:57, Xinze Chi (信泽) wrote:
>>>>>
>>>>> You mean your ceph assert(0 == "bl should be align"), right?
>>>>>
>>>>> But in master branch, the 1036 line is not assert(0 == "bl should be
>>>>> align").
>>>>
>>>>
>>>> Yes you are correct. I think I have some heade #includes why this moves
>>>> down in my file.
>>>>
>>>> None the less I still get trapped on that specific assert.
>>>>
>>>> Next question is of course why this code is what it is. Since once the
>>>> assert triggers, the remainder does not get executed.
>>>> Unless compiled with NDEBUG, then only the warning gets printed.
>>>> But the other asserts never get triggered.
>>>>
>>>> So back to my original question, Why have this very stringent test and
>>>> than in test/buffer.cc forgo the fact that this could/should be aligned.
>>>>
>>>> --WjW
>>>>
>>>>
>>>>> 2015-12-16 7:56 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm receiving traps when running the tests going with 'gmake check'
>>>>>> and on one of the tests it traps on:
>>>>>>
>>>>>> os/FileJournal.cc:1036
>>>>>> void FileJournal::align_bl(off64_t pos, bufferlist& bl)
>>>>>> {
>>>>>>// make sure list segments are page aligned
>>>>>>if (directio && (!bl.is_aligned(block_size) ||
>>>>>> !bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
>>>>>> assert(0 == "bl should be align");
>>>>>> if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
>>>>>> (pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
>>>>>>dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
>>>>>> assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>>>>>> assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>>>>>>}
>>>>>> }
>>>>>>
>>>>>> And then I get confused with the following commit in other tests:
>>>>>> commit 8ed724222651812c2ee8cc3804dc1f54c973897d
>>>>>> Author: Kefu Chai <kc...@redhat.com>
>>>>>> Date: Fri Sep 4 01:23:31 2015 +0800
>>>>>>
>>>>>> test/bufferlist: do not expect !is_page_aligned() after unaligned
>>>>>> rebuild
>>>>>>
>>>>>> if the size of a bufferlist is page aligned we allocate page
>>>>>> aligned
>>>>>> memory chunk for it when rebuild() is called. otherwise we just
>>>
Re: cmake
On 16-12-2015 19:45, Yehuda Sadeh-Weinraub wrote:
> Is cmake a viable option in all environments we expect ceph (or any
> part of) to be compiled on? (e.g. aix, solaris, freebsd, different
> linux arm distros, etc.)
Hi,
For FreeBSD it does not really matter much. Recently the native builder
has become bmake (and is called as make).
To build things for Ceph I needed to install gmake and actually call it
like that, aka. gmake check
It is easily installed as a package, and currently I've worked out most
required packages. The ports building platform allow for specifying the
required packages, as well as specifying which make to use. This
includes using Cmake. If a package requires {C,f,g}make and that make is
lacking, the package system first installs it.
It is not easy to actually to accommodate for FreeBSD in the autotools
with the current configure.ac and stuff. But I haven't looked at the
Cmake stuff to see if it gets any easier.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cmake
On 16-12-2015 20:38, Sage Weil wrote:
> On Wed, 16 Dec 2015, Matt Benjamin wrote:
>> I'm going to push for cmake work already in progress to be moved to the
>> next milestone ASAP.
>>
>> With respect to "make check" blockers, which contains the issue of where
>> cmake puts built objects. Ali, Casey, and I discussed this today at
>> some length. We think the current "hackery" to make cmake make check
>> work "the same way" auto* did is long-term undesirable due to it
>> mutating files in the src dir. I have not assumed that it would be an
>> improvement to put all objects built in a tree of submakes into a single
>> dir, as automake does. I do think it is essential that at least
>> eventually, it makes it simple to operate on any object that is built,
>> and simple to extend processes like make check.
>
> All of the binaries eventually go into /usr[/local]/bin anyway. Can we
> do the same here? (I don't care where intermediate .lo or .o objects
> go...)
Why not take it one step further and have something like:
/ceph/build/{bin,sbin,lib,libexec,etc,tmp,test,log,.}
which would be separate tree part where all the stuff is build.
Cleaning up will then also become a lot easier ATM the stuff in .lib
is not cleaned, I think.
It would also allow to process scripts to fit the local OS by running it
thru m4/sed/awk/perl/...
Or if you prefer so, hang it of /ceph/src
But then again this might require something like: make install-build
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD is receiving traps on os/FileJournal.cc:1036
On 16-12-2015 13:51, Xinze Chi (信泽) wrote:
Would you mind create an issue in http://tracker.ceph.com/ and tell me
how to reproduce the bug?
You are aware that that requires running FreeBSD?
I will enter a ticket into the tracker.
--WjW
Thanks.
2015-12-16 18:26 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
On 16-12-2015 10:40, Xinze Chi (信泽) wrote:
Because we use the new strategy for filejournal in master branch. the
write entry submit to writeq is aligned already.
So if assert at this line, this strategy should have bug.
I do not know why you have some heads #include, Maybe you modify the
logic in filejournal?
No, the adds I've done are to work around the fact that the linux_version
stuff
is not really going to work for FreeBSD. Not the test, nor the resulting
code.
So the header part of the file now looks like:
#include "common/blkdev.h"
#if defined(__linux__)
#include "common/linux_version.h"
#endif
#if defined(__FreeBSD__)
#include "common/freebsd_version.h"
#define O_DSYNC O_SYNC
#endif
The remainder of the diffs are about locking when using aio, which i do not
ATM.
So never say never with software, but I think I've left the logic as it
is/was.
--WjW
2015-12-16 17:20 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
On 16-12-2015 02:57, Xinze Chi (信泽) wrote:
You mean your ceph assert(0 == "bl should be align"), right?
But in master branch, the 1036 line is not assert(0 == "bl should be
align").
Yes you are correct. I think I have some heade #includes why this moves
down in my file.
None the less I still get trapped on that specific assert.
Next question is of course why this code is what it is. Since once the
assert triggers, the remainder does not get executed.
Unless compiled with NDEBUG, then only the warning gets printed.
But the other asserts never get triggered.
So back to my original question, Why have this very stringent test and
than in test/buffer.cc forgo the fact that this could/should be aligned.
--WjW
2015-12-16 7:56 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
Hi,
I'm receiving traps when running the tests going with 'gmake check'
and on one of the tests it traps on:
os/FileJournal.cc:1036
void FileJournal::align_bl(off64_t pos, bufferlist& bl)
{
// make sure list segments are page aligned
if (directio && (!bl.is_aligned(block_size) ||
!bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
assert(0 == "bl should be align");
if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
(pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
}
}
And then I get confused with the following commit in other tests:
commit 8ed724222651812c2ee8cc3804dc1f54c973897d
Author: Kefu Chai <kc...@redhat.com>
Date: Fri Sep 4 01:23:31 2015 +0800
test/bufferlist: do not expect !is_page_aligned() after unaligned
rebuild
if the size of a bufferlist is page aligned we allocate page
aligned
memory chunk for it when rebuild() is called. otherwise we just
call
the plain new() to allocate new memory chunk for holding the
continuous
buffer. but we should not expect that `new` allocator always
returns
unaligned memory chunks. instead, it *could* return page aligned
memory chunk as long as the allocator feels appropriate. so, the
`EXPECT_FALSE(bl.is_page_aligned())` after the `rebuild()` call is
removed.
Signed-off-by: Kefu Chai <kc...@redhat.com>
Could these 2 be related, and do I have an alignment problem when
allocating buffers and bufferlists
Note that I also have not solved the illegal writes to _len in
bufferlists when running unittest_erasure_code_shec_arguments.
So any suggestions as to where to look at for this, are welcome.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD is receiving traps on os/FileJournal.cc:1036
On 16-12-2015 02:57, Xinze Chi (信泽) wrote:
> You mean your ceph assert(0 == "bl should be align"), right?
>
> But in master branch, the 1036 line is not assert(0 == "bl should be align").
Yes you are correct. I think I have some heade #includes why this moves
down in my file.
None the less I still get trapped on that specific assert.
Next question is of course why this code is what it is. Since once the
assert triggers, the remainder does not get executed.
Unless compiled with NDEBUG, then only the warning gets printed.
But the other asserts never get triggered.
So back to my original question, Why have this very stringent test and
than in test/buffer.cc forgo the fact that this could/should be aligned.
--WjW
> 2015-12-16 7:56 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
>> Hi,
>>
>> I'm receiving traps when running the tests going with 'gmake check'
>> and on one of the tests it traps on:
>>
>> os/FileJournal.cc:1036
>> void FileJournal::align_bl(off64_t pos, bufferlist& bl)
>> {
>> // make sure list segments are page aligned
>> if (directio && (!bl.is_aligned(block_size) ||
>>!bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
>> assert(0 == "bl should be align");
>> if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
>> (pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
>> dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
>> assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>> assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>> }
>> }
>>
>> And then I get confused with the following commit in other tests:
>> commit 8ed724222651812c2ee8cc3804dc1f54c973897d
>> Author: Kefu Chai <kc...@redhat.com>
>> Date: Fri Sep 4 01:23:31 2015 +0800
>>
>> test/bufferlist: do not expect !is_page_aligned() after unaligned
>> rebuild
>>
>> if the size of a bufferlist is page aligned we allocate page aligned
>> memory chunk for it when rebuild() is called. otherwise we just call
>> the plain new() to allocate new memory chunk for holding the continuous
>> buffer. but we should not expect that `new` allocator always returns
>> unaligned memory chunks. instead, it *could* return page aligned
>> memory chunk as long as the allocator feels appropriate. so, the
>> `EXPECT_FALSE(bl.is_page_aligned())` after the `rebuild()` call is
>> removed.
>>
>> Signed-off-by: Kefu Chai <kc...@redhat.com>
>>
>> Could these 2 be related, and do I have an alignment problem when
>> allocating buffers and bufferlists
>>
>> Note that I also have not solved the illegal writes to _len in
>> bufferlists when running unittest_erasure_code_shec_arguments.
>>
>> So any suggestions as to where to look at for this, are welcome.
>>
>> --WjW
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FreeBSD is receiving traps on os/FileJournal.cc:1036
On 16-12-2015 10:40, Xinze Chi (信泽) wrote:
Because we use the new strategy for filejournal in master branch. the
write entry submit to writeq is aligned already.
So if assert at this line, this strategy should have bug.
I do not know why you have some heads #include, Maybe you modify the
logic in filejournal?
No, the adds I've done are to work around the fact that the
linux_version stuff
is not really going to work for FreeBSD. Not the test, nor the resulting
code.
So the header part of the file now looks like:
#include "common/blkdev.h"
#if defined(__linux__)
#include "common/linux_version.h"
#endif
#if defined(__FreeBSD__)
#include "common/freebsd_version.h"
#define O_DSYNC O_SYNC
#endif
The remainder of the diffs are about locking when using aio, which i do
not ATM.
So never say never with software, but I think I've left the logic as it
is/was.
--WjW
2015-12-16 17:20 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
On 16-12-2015 02:57, Xinze Chi (信泽) wrote:
You mean your ceph assert(0 == "bl should be align"), right?
But in master branch, the 1036 line is not assert(0 == "bl should be align").
Yes you are correct. I think I have some heade #includes why this moves
down in my file.
None the less I still get trapped on that specific assert.
Next question is of course why this code is what it is. Since once the
assert triggers, the remainder does not get executed.
Unless compiled with NDEBUG, then only the warning gets printed.
But the other asserts never get triggered.
So back to my original question, Why have this very stringent test and
than in test/buffer.cc forgo the fact that this could/should be aligned.
--WjW
2015-12-16 7:56 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
Hi,
I'm receiving traps when running the tests going with 'gmake check'
and on one of the tests it traps on:
os/FileJournal.cc:1036
void FileJournal::align_bl(off64_t pos, bufferlist& bl)
{
// make sure list segments are page aligned
if (directio && (!bl.is_aligned(block_size) ||
!bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
assert(0 == "bl should be align");
if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
(pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
}
}
And then I get confused with the following commit in other tests:
commit 8ed724222651812c2ee8cc3804dc1f54c973897d
Author: Kefu Chai <kc...@redhat.com>
Date: Fri Sep 4 01:23:31 2015 +0800
test/bufferlist: do not expect !is_page_aligned() after unaligned
rebuild
if the size of a bufferlist is page aligned we allocate page aligned
memory chunk for it when rebuild() is called. otherwise we just call
the plain new() to allocate new memory chunk for holding the continuous
buffer. but we should not expect that `new` allocator always returns
unaligned memory chunks. instead, it *could* return page aligned
memory chunk as long as the allocator feels appropriate. so, the
`EXPECT_FALSE(bl.is_page_aligned())` after the `rebuild()` call is
removed.
Signed-off-by: Kefu Chai <kc...@redhat.com>
Could these 2 be related, and do I have an alignment problem when
allocating buffers and bufferlists
Note that I also have not solved the illegal writes to _len in
bufferlists when running unittest_erasure_code_shec_arguments.
So any suggestions as to where to look at for this, are welcome.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
FreeBSD is receiving traps on os/FileJournal.cc:1036
Hi,
I'm receiving traps when running the tests going with 'gmake check'
and on one of the tests it traps on:
os/FileJournal.cc:1036
void FileJournal::align_bl(off64_t pos, bufferlist& bl)
{
// make sure list segments are page aligned
if (directio && (!bl.is_aligned(block_size) ||
!bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
assert(0 == "bl should be align");
if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
(pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
}
}
And then I get confused with the following commit in other tests:
commit 8ed724222651812c2ee8cc3804dc1f54c973897d
Author: Kefu Chai
Date: Fri Sep 4 01:23:31 2015 +0800
test/bufferlist: do not expect !is_page_aligned() after unaligned
rebuild
if the size of a bufferlist is page aligned we allocate page aligned
memory chunk for it when rebuild() is called. otherwise we just call
the plain new() to allocate new memory chunk for holding the continuous
buffer. but we should not expect that `new` allocator always returns
unaligned memory chunks. instead, it *could* return page aligned
memory chunk as long as the allocator feels appropriate. so, the
`EXPECT_FALSE(bl.is_page_aligned())` after the `rebuild()` call is
removed.
Signed-off-by: Kefu Chai
Could these 2 be related, and do I have an alignment problem when
allocating buffers and bufferlists
Note that I also have not solved the illegal writes to _len in
bufferlists when running unittest_erasure_code_shec_arguments.
So any suggestions as to where to look at for this, are welcome.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, trouble in buffer.c
On 10-12-2015 16:03, Willem Jan Withagen wrote:
I have a failure in:
./unittest_erasure_code_shec_arguments
All tests befor this PASS. (other than rbd which is disabled to
the time being)
Which I traceback to code in ErasureCodeShec.cc
Line 218:
unsigned blocksize = (*chunks.begin()).second.length();
After a few iterations I get a "negative" blocksize, which causes
allocations further on to really thrash the system out of swap.
At first I expected it could be due to a Clang typecasting problem.
But after more debugging I found the following in
buffer.h
unsigned length() const {
#if 0
// DEBUG: verify _len
unsigned len = 0;
for (std::list::const_iterator it = _buffers.begin();
it != _buffers.end();
it++) {
len += (*it).length();
}
assert(len == _len);
#endif
return _len;
}
Which suggests that debugging was needed at this point earlier in life.
If I enable this debug block, I do get the assert affected.
Now the next question is why? Given the debug snippet it needed
analyzing before.
And the derived question then is:
What is the easiest path to find out what is actually wrong here.
A further followup on this.
After some extensive debugging with gdb and watches, I've come to the
conclusion
That the location of _len is used by more that one part of the code...
The location gets alternately written during:
TestErasureCodeShec_arguments.cc:136
shec_table.insert(std::make_pair(table_key,table_value));
Old value = 63015016
New value = 4294954344
Old value = 4294954344
New value = 63015016
.
To retain this value 4294954344, which is definitely not the length.
Because printing values on the Linux variant, it gives 32. Which sounds
much more
sensible
So there a few possibilities that I can think of:
1) Clang gets it wrong
2) There is a mixup of different type of libs that make for different
offsets in
the bufferlist structs
3) the bufferlist code is has portability issues
4) the bufferlist code has errors that do no show with gcc
Most likely it will be either 2) or 3)
But other suggestions are welcome...
And since bufferlists are at the center of Ceph, better get things right.
So I'm going to go over the test/bufferlist.cc code and see what is in
there.
And/or extract a less convoluted example from
TestErasureCodeShec_arguments.cc
and see if it is in there as well.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, trouble in buffer.c
I have a failure in:
./unittest_erasure_code_shec_arguments
All tests befor this PASS. (other than rbd which is disabled to
the time being)
Which I traceback to code in ErasureCodeShec.cc
Line 218:
unsigned blocksize = (*chunks.begin()).second.length();
After a few iterations I get a "negative" blocksize, which causes
allocations further on to really thrash the system out of swap.
At first I expected it could be due to a Clang typecasting problem.
But after more debugging I found the following in
buffer.h
unsigned length() const {
#if 0
// DEBUG: verify _len
unsigned len = 0;
for (std::list::const_iterator it = _buffers.begin();
it != _buffers.end();
it++) {
len += (*it).length();
}
assert(len == _len);
#endif
return _len;
}
Which suggests that debugging was needed at this point earlier in life.
If I enable this debug block, I do get the assert affected.
Now the next question is why? Given the debug snippet it needed
analyzing before.
And the derived question then is:
What is the easiest path to find out what is actually wrong here.
All suggestions welcome.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, Clang refuses to compile a test
On 8-12-2015 01:29, Willem Jan Withagen wrote: On 7-12-2015 23:19, Michal Jarzabek wrote: Hi Willem, If you look at line 411 and 412 you will have variables k and m defined. They are not changed anywhere(I think), so the sizes must be big enough. As Xinze mentioned just add const in front of it: const int k = 12 const int m = 4 and it should fix the compile error. buffer::ptr enc[k + m] works with gcc, because of the compiler extension, but it's not standard c++(https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html) I will submit patch to change it. That is exactly what I have done to get things compiling. Have not yet gotten to the state that everything builds to start testing. Testing has started Not everything goes well, but it is getting there. Had to disable ebd testing as that still does not get build. But I think I saw a patch passing by that it only got build for Linux. And the tests below tooks to run for atleast 7 hours on a CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) So what I gather from that is that that is too long. Some tests (like: unittest_erasure_code_shec_thread) got killed because they ran out of swap, others (unittest_on_exit) got a signal 6... But then again that could be because the gtest ASSERT_DEATH stuff is not suppoorted under FreeBSD (as by words of Google) --WjW PASS: unittest_erasure_code_plugin PASS: unittest_erasure_code PASS: unittest_erasure_code_jerasure PASS: unittest_erasure_code_plugin_jerasure PASS: unittest_erasure_code_isa PASS: unittest_erasure_code_plugin_isa PASS: unittest_erasure_code_lrc PASS: unittest_erasure_code_plugin_lrc PASS: unittest_erasure_code_shec PASS: unittest_erasure_code_shec_all PASS: unittest_erasure_code_shec_thread Killed FAIL: unittest_erasure_code_shec_arguments PASS: unittest_erasure_code_plugin_shec PASS: unittest_erasure_code_example PASS: unittest_librados PASS: unittest_librados_config PASS: unittest_journal PASS: unittest_rbd_replay PASS: unittest_encoding PASS: unittest_base64 PASS: unittest_run_cmd PASS: unittest_simple_spin PASS: unittest_libcephfs_config PASS: unittest_mon_moncap PASS: unittest_mon_pgmap PASS: unittest_ecbackend PASS: unittest_osdscrub PASS: unittest_pglog PASS: unittest_hitset PASS: unittest_osd_osdcap PASS: unittest_pageset PASS: unittest_chain_xattr PASS: unittest_lfnindex PASS: unittest_mds_authcap PASS: unittest_addrs PASS: unittest_bloom_filter PASS: unittest_histogram PASS: unittest_prioritized_queue PASS: unittest_str_map PASS: unittest_sharedptr_registry PASS: unittest_shared_cache PASS: unittest_sloppy_crc_map PASS: unittest_util PASS: unittest_crush_wrapper PASS: unittest_crush PASS: unittest_osdmap PASS: unittest_workqueue PASS: unittest_striper PASS: unittest_prebufferedstreambuf PASS: unittest_str_list PASS: unittest_log PASS: unittest_throttle PASS: unittest_ceph_argparse PASS: unittest_ceph_compatset PASS: unittest_mds_types PASS: unittest_osd_types PASS: unittest_lru PASS: unittest_io_priority PASS: unittest_gather PASS: unittest_signals PASS: unittest_bufferlist PASS: unittest_xlist PASS: unittest_crc32c PASS: unittest_arch PASS: unittest_crypto PASS: unittest_crypto_init PASS: unittest_perf_counters PASS: unittest_admin_socket PASS: unittest_ceph_crypto PASS: unittest_utf8 PASS: unittest_mime PASS: unittest_escape PASS: unittest_strtol PASS: unittest_confutils PASS: unittest_config PASS: unittest_context PASS: unittest_safe_io PASS: unittest_heartbeatmap PASS: unittest_formatter PASS: unittest_daemon_config PASS: unittest_ipaddr PASS: unittest_texttable Abort trap (core dumped) FAIL: unittest_on_exit PASS: unittest_readahead PASS: unittest_tableformatter PASS: unittest_bit_vector FAIL: ceph-detect-init/run-tox.sh FAIL: test/erasure-code/test-erasure-code.sh FAIL: test/erasure-code/test-erasure-eio.sh -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 4-12-2015 21:11, Willem Jan Withagen wrote: One larger problem with libraries I have is the stuff with dlopen. In ./configure it seems that most of the code is short-circuited, and -ldl gets appended in the Makefile.am's by default. The code there is rather hard to parse. FreeBSD has this in libc, so no specific includes needed. Now the question is how do I cleanly fix this without breaking just about every other platform? Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 4-12-2015 21:11, Willem Jan Withagen wrote: On 4-12-2015 19:44, Gregory Farnum wrote: On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen <w...@digiware.nl> wrote: On 3-12-2015 01:27, Yan, Zheng wrote: On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <w...@digiware.nl> wrote: On 2-12-2015 15:13, Yan, Zheng wrote: I see that you have disabled uuid? Might I ask why? not disable. Currently ceph uses boost uuid implementation. so no need to link to libuuid. And The uuid transition to boost::uuid has happened since then (a few months back) and I believe Rohan's AIX and Solaris ports for librados (that just merged) included a fix for the sockaddr_storage issue: I cannot seem to find the package or port that defines boost::uuid. So how did you make it available to the build system? http://www.boost.org/doc/libs/1_59_0/libs/uuid/ It's part of the boost labyrinth. I think in Debian it's just part of libboost-dev, but you might need to dig around in whatever packaging you're using for FreeBSD. I've dumped all of the labels in de boost libraries. So it is not default available with the pre-build packages. Which is understandable given the size of all that is available in boost. But lets go and fetch/build some of that stuff. For the time being I've chosen to use the misc/e2fsprogs-libuuid package. Reason for this is that is easily installed, instead of going thru the motions of manually downloading/compiling a boost library. Once boost-uuid is available reverting is easy. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 8-12-2015 13:36, Mykola Golub wrote: On Tue, Dec 08, 2015 at 11:04:13AM +0100, Willem Jan Withagen wrote: On 4-12-2015 21:11, Willem Jan Withagen wrote: One larger problem with libraries I have is the stuff with dlopen. In ./configure it seems that most of the code is short-circuited, and -ldl gets appended in the Makefile.am's by default. The code there is rather hard to parse. FreeBSD has this in libc, so no specific includes needed. Now the question is how do I cleanly fix this without breaking just about every other platform? Could you provide particular examples? Because what I see in the master is usually like below: if LINUX xio_server_LDADD += -ldl endif If you see somewhere -ldl is added unconditionally it is likely to have to be fixed the same way. Several of the test makefiles did not have this. For this I've patched at least: src/tools/Makefile-server.am src/tracing/Makefile.am src/erasure-code/Makefile.am src/rgw/Makefile.am And this is indeed what I've added ATM to get my tests compiled. But I really wonder if this is the way to go, instead of fixing it in configure and be done with it. Just like wiht most of the other libraries that are setup thru automake/configure. That would also help other ports, then for that port one does not have to augment again all locations. AND if new tests would be written, we do not have to check if all exempts are correctly covered. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, Clang refuses to compile a test
On 5-12-2015 14:02, Xinze Chi (信泽) wrote:
I think "const int k = 12; const int m = 4" would pass the compile?
Are these sizes big enough??
--WjW
2015-12-05 20:56 GMT+08:00 Willem Jan Withagen <w...@digiware.nl>:
src/test/erasure-code/TestErasureCodeIsa.cc
contains snippets, function definition like:
buffer::ptr enc[k + m];
// create buffers with a copy of the original data to be able to compare
it after decoding
{
for (int i = 0; i < (k + m); i++) {
Clang refuses because the [k+m] size in not known at compiletime.
Suggesting to tempate this.
How would one normally handle this?
I've temporarily made it fixed size 1024*1024.
But I'm not sure if that is big enough
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, Clang refuses to compile a test
On 7-12-2015 23:19, Michal Jarzabek wrote: Hi Willem, If you look at line 411 and 412 you will have variables k and m defined. They are not changed anywhere(I think), so the sizes must be big enough. As Xinze mentioned just add const in front of it: const int k = 12 const int m = 4 and it should fix the compile error. buffer::ptr enc[k + m] works with gcc, because of the compiler extension, but it's not standard c++(https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html) I will submit patch to change it. That is exactly what I have done to get things compiling. Have not yet gotten to the state that everything builds to start testing. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, Clang refuses to compile a test
src/test/erasure-code/TestErasureCodeIsa.cc
contains snippets, function definition like:
buffer::ptr enc[k + m];
// create buffers with a copy of the original data to be able to
compare it after decoding
{
for (int i = 0; i < (k + m); i++) {
Clang refuses because the [k+m] size in not known at compiletime.
Suggesting to tempate this.
How would one normally handle this?
I've temporarily made it fixed size 1024*1024.
But I'm not sure if that is big enough
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 4-12-2015 19:44, Gregory Farnum wrote: > On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen <w...@digiware.nl> wrote: >> On 3-12-2015 01:27, Yan, Zheng wrote: >>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <w...@digiware.nl> >>> wrote: >>>> On 2-12-2015 15:13, Yan, Zheng wrote: >> >>>> I see that you have disabled uuid? >>>> Might I ask why? >>> >>> not disable. Currently ceph uses boost uuid implementation. so no need >>> to link to libuuid. >> >> And >> >>>>>>> The uuid transition to boost::uuid has happened since then (a few months >>>>>>> back) and I believe Rohan's AIX and Solaris ports for librados (that >>>>>>> just >>>>>>> merged) included a fix for the sockaddr_storage issue: >> >> I cannot seem to find the package or port that defines boost::uuid. >> So how did you make it available to the build system? > > http://www.boost.org/doc/libs/1_59_0/libs/uuid/ > > It's part of the boost labyrinth. I think in Debian it's just part of > libboost-dev, but you might need to dig around in whatever packaging > you're using for FreeBSD. I've dumped all of the labels in de boost libraries. So it is not default available with the pre-build packages. Which is understandable given the size of all that is available in boost. But lets go and fetch/build some of that stuff. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 3-12-2015 01:27, Yan, Zheng wrote: > On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <w...@digiware.nl> wrote: >> On 2-12-2015 15:13, Yan, Zheng wrote: >> I see that you have disabled uuid? >> Might I ask why? > > not disable. Currently ceph uses boost uuid implementation. so no need > to link to libuuid. And >>>>> The uuid transition to boost::uuid has happened since then (a few months >>>>> back) and I believe Rohan's AIX and Solaris ports for librados (that just >>>>> merged) included a fix for the sockaddr_storage issue: I cannot seem to find the package or port that defines boost::uuid. So how did you make it available to the build system? Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, runtimes for seperate tests.
On 2-12-2015 22:10, Willem Jan Withagen wrote: Running gmake check Now I start wondering how long certain tests are able to run: I've killed: unittest_chain_xattr because it was running already voor 12 hours. And unittest_lfnindex is also running for > 20 minutes Is there a way to specify something like a max runtime for these tests? So that I am able to run the testset repeatedly, to monitor regression once I start changing code. I saw Loic talk about some of the expected test runtimes. But having a better feeling per specific test would be useful in getting the test to progress Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, runtimes for seperate tests.
On 3-12-2015 10:50, Willem Jan Withagen wrote: On 2-12-2015 22:10, Willem Jan Withagen wrote: Running gmake check Now I start wondering how long certain tests are able to run: I've killed: unittest_chain_xattr because it was running already voor 12 hours. And unittest_lfnindex is also running for > 20 minutes Is there a way to specify something like a max runtime for these tests? So that I am able to run the testset repeatedly, to monitor regression once I start changing code. I saw Loic talk about some of the expected test runtimes. But having a better feeling per specific test would be useful in getting the test to progress Excluded all rbd tests, and killed some of the processes that ran > 1200 secs. But below the results... Need to figure the Makefiles out to exclude rbd testing. And perhaps start a timelimit on running processes. --WjW Testsuite summary for ceph 10.0.0 # TOTAL: 119 # PASS: 87 # SKIP: 0 # XFAIL: 0 # FAIL: 32 # XPASS: 0 # ERROR: 0 See src/test-suite.log Please report to ceph-devel@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, missing rbd
On 3-12-2015 13:34, Mykola Golub wrote: > On Wed, Dec 02, 2015 at 11:47:04PM +0100, Willem Jan Withagen wrote: >> >> Running gmake check is starting to work. >> reporting still thinks there are no successful tests >> but tests themselves report OKE >> >> But where I really can not get it to work is with testing rbd. >> >> Is starts with the simple: >> /bin/sh: rbd: not found >> >> And whatever I'm trying in configure, no way am I able to get either an >> executable or a script that will do rbd >> >> So how do I get a rbd that can be used in the tests. > > On the master rbd is built on Linux only, see src/tools/Makefile-client.am. > > I have a patch in my branch that makes rbd build on all platforms > (excluding kernel bits): > > https://github.com/trociny/ceph/commit/cd427e3ef2a5a307d6649e5b1dcfefdf67d60b29 > > But large rbd refactoring has happened in master since that time, and > my patch requires some work to apply on the current master. > Oke, Is see the patch, which is simple enough. Now when code has been moved around, I can imagine that there is going to be some work required. It's going on the list. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 2-12-2015 15:13, Yan, Zheng wrote: > see https://github.com/ceph/ceph/pull/6770. The code can be compiled > on FreeBSD/OSX, most client programs can connect to ceph servers on > Linux. Hi, I do like some of the inline compiler tests. I guess that the way the errno's are done like the other OS's have done as well? I'd normally solve this with a static array, and just index it. But perhaps the compiler is smart enough to do the same. I see that you have disabled uuid? Might I ask why? I Suggest you have a look at the issue Alan brought up. Which is a possible fix for doing it the other way around: Linux clients on a FreeBSD "cluster" But as Sage suggest: Could be very well solved by fixed brougt in for AIX. --WjW > Regards > Yan. Zheng > > On Wed, Dec 2, 2015 at 2:43 AM, Willem Jan Withagen <w...@digiware.nl> wrote: >> On 1-12-2015 19:36, Sage Weil wrote: >>> >>> On Tue, 1 Dec 2015, Alan Somers wrote: >>>> >>>> On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <w...@digiware.nl> >>>> wrote: >>>>> >>>>> On 1-12-2015 18:22, Alan Somers wrote: >>>>>> >>>>>> >>>>>> I did some work porting Ceph to FreeBSD, but got distracted and >>>>>> stopped about two years ago. You may find this port useful, though it >>>>>> will probably need to be updated: >>>>>> >>>>>> https://people.freebsd.org/~asomers/ports/net/ceph/ >>>>> >>>>> >>>>> >>>>> I'll chcek that one as well... >>>>> >>>>>> Also, there's one major outstanding issue that I know of. It breaks >>>>>> interoperability between FreeBSD and Linux Ceph nodes. I posted a >>>>>> patch to fix it, but it doesn't look like it's been merged yet. >>>>>> http://tracker.ceph.com/issues/6636 >>>>> >>>>> >>>>> >>>>> In the issues I find: >>>>> >>>>> Updated by Sage Weil almost 2 years ago >>>>> >>>>> Status changed from New to Verified >>>>> Updated by Sage Weil almost 2 years ago >>>>> >>>>> Assignee set to Noah Watkins >>>>> >>>>> >>>>> Probably left at that point because there was no presure to actually >>>>> commit? >>>>> >>>>> --WjW >>>> >>>> >>>> It looks like Sage reviewed the change, but had some comments that >>>> were mostly style-related. Neither Noah nor I actually got around to >>>> implementing Sage's suggestions. >>>> >>>> https://github.com/ceph/ceph/pull/828 >>> >>> >>> The uuid transition to boost::uuid has happened since then (a few months >>> back) and I believe Rohan's AIX and Solaris ports for librados (that just >>> merged) included a fix for the sockaddr_storage issue: >>> >>> https://github.com/ceph/ceph/blob/master/src/msg/msg_types.h#L180 >>> >>> and also >>> >>> https://github.com/ceph/ceph/blob/master/src/msg/msg_types.h#L160 >> >> >> >> Would be nice to actually find that this works for FreeBSD as well. >> But I'm putting this on the watch-list, once I get there. >> >> --WjW > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 19:51, Willem Jan Withagen wrote:
> On 1-12-2015 17:24, Willem Jan Withagen wrote:
>> I think in the short run it will not be the code that is going to be a
>> major porting pain. But getting the run-time environment ironed out is
>> just plain (hard) work. Things where /bin/sh expects certain bash-isms.
>> Where paths have not been setup to the fullest all the way back into
>> ./configure: like ${initrddir} => /etc/init.d versus /usr/local/etc/rc.d.
>> Probably plenty more like these.
>
> To answer myself:
> grep != grep
>
> freetest# grep -P test *
> grep: The -P option is not supported
>
> :(
>
> And only to match things like:
> ceph-authtool kring --list|grep -P '^\tcaps '
>
> Start looking for a mode that works could work on both
Looks like that will be something along the lines of
grep -E '^\Wtcaps'
And that gets a lot of tests accepted.
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD, missing rbd
Running gmake check is starting to work. reporting still thinks there are no successful tests but tests themselves report OKE But where I really can not get it to work is with testing rbd. Is starts with the simple: /bin/sh: rbd: not found And whatever I'm trying in configure, no way am I able to get either an executable or a script that will do rbd So how do I get a rbd that can be used in the tests. What I do have is rbdmap, but that is a totally different thingy. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 15:35, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
On 1-12-2015 14:30, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
On 30-11-2015 14:21, Sage Weil wrote:
The problem with all of the porting code in general is that it is doomed
to break later on if we don't have (at least) ongoing build tests. In
order for a FreeBSD or OSX port to continue working we need VMs that run
either gitbuilder or a jenkins job or similar so that we can tell when
it
breaks.
If someone is willing to run a VM somewhere to do this we can pretty
easily stick it on the gitbuilder page at
http://ceph.com/gitbuilder.cgi
Hi Sage,
Could you give some pointers as to where to start running the tests.
I see a lot of "basic" tests to see if the platform is actually
conformant.
So before plunging into running ceph-mon and stuff, it would perhaps be
better to actually run (parts of) the basic required tests..
I would start with 'make check' from src/... that's what we'd actually
want the gitbuilder to do.
I was running that at the moment
Found the suggestion on the developers pages, in the manual section.
Sort of hidden at the bottom. :)
Did kill it in between, but now when I run it, it just only generates the
report.
So I just went make clean, which is rather too much...
But could not really figure out the makefiles in test (yet)
How do I reset the test results?
I don't think there is anything to reset... just re-ru make check. The
exception is probably just if you hit control-c but it left running
processes behind (./stop.sh should clean those up).
'mmm,
Strange I had it generate tests at one point.
And now just plain nothing
Server has rebooted, so there should have nothing been left.
At least, that's the case on Linux.. maybe the (auto)tools are a bit
different on *BSD?
I think in the short run it will not be the code that is going to be a
major porting pain. But getting the run-time environment ironed out is
just plain (hard) work. Things where /bin/sh expects certain bash-isms.
Where paths have not been setup to the fullest all the way back into
./configure: like ${initrddir} => /etc/init.d versus /usr/local/etc/rc.d.
Probably plenty more like these.
I've also seen calls in the code to things like:
arch
hdparm
things that just are not there in (basic) FreeBSD
But we'll get around al of that.
I survived porting Unix tools (including UUCP) to Win95 and OS/2. So
until we get to kernel things I just keep pushing along.
Just for clarity:
Gitbuilder just runs:
make check
and collects the output?
So that would be the way to tackle this, get complete (successful) output
from:
gmake clean && gmake test
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You may find this port useful, though it will probably need to be updated: https://people.freebsd.org/~asomers/ports/net/ceph/ I'll chcek that one as well... Also, there's one major outstanding issue that I know of. It breaks interoperability between FreeBSD and Linux Ceph nodes. I posted a patch to fix it, but it doesn't look like it's been merged yet. http://tracker.ceph.com/issues/6636 In the issues I find: Updated by Sage Weil almost 2 years ago Status changed from New to Verified Updated by Sage Weil almost 2 years ago Assignee set to Noah Watkins Probably left at that point because there was no presure to actually commit? --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 19:21, Alan Somers wrote: On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <w...@digiware.nl> wrote: On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You may find this port useful, though it will probably need to be updated: https://people.freebsd.org/~asomers/ports/net/ceph/ I'll chcek that one as well... Also, there's one major outstanding issue that I know of. It breaks interoperability between FreeBSD and Linux Ceph nodes. I posted a patch to fix it, but it doesn't look like it's been merged yet. http://tracker.ceph.com/issues/6636 In the issues I find: Updated by Sage Weil almost 2 years ago Status changed from New to Verified Updated by Sage Weil almost 2 years ago Assignee set to Noah Watkins Probably left at that point because there was no presure to actually commit? --WjW It looks like Sage reviewed the change, but had some comments that were mostly style-related. Neither Noah nor I actually got around to implementing Sage's suggestions. https://github.com/ceph/ceph/pull/828 Come to realise that this is about interoperability Linux <> FreeBSD. Which is a problem when running a mix of nodes. First I'm focussing on getting an all FreeBSD to configure compile test-run Then see if we can actually build and run a dev-cluster up. So your warning is very much appricated, but I'm not anywhere near that point. :( --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 19:36, Sage Weil wrote: On Tue, 1 Dec 2015, Alan Somers wrote: On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <w...@digiware.nl> wrote: On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You may find this port useful, though it will probably need to be updated: https://people.freebsd.org/~asomers/ports/net/ceph/ I'll chcek that one as well... Also, there's one major outstanding issue that I know of. It breaks interoperability between FreeBSD and Linux Ceph nodes. I posted a patch to fix it, but it doesn't look like it's been merged yet. http://tracker.ceph.com/issues/6636 In the issues I find: Updated by Sage Weil almost 2 years ago Status changed from New to Verified Updated by Sage Weil almost 2 years ago Assignee set to Noah Watkins Probably left at that point because there was no presure to actually commit? --WjW It looks like Sage reviewed the change, but had some comments that were mostly style-related. Neither Noah nor I actually got around to implementing Sage's suggestions. https://github.com/ceph/ceph/pull/828 The uuid transition to boost::uuid has happened since then (a few months back) and I believe Rohan's AIX and Solaris ports for librados (that just merged) included a fix for the sockaddr_storage issue: https://github.com/ceph/ceph/blob/master/src/msg/msg_types.h#L180 and also https://github.com/ceph/ceph/blob/master/src/msg/msg_types.h#L160 Would be nice to actually find that this works for FreeBSD as well. But I'm putting this on the watch-list, once I get there. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 17:24, Willem Jan Withagen wrote:
I think in the short run it will not be the code that is going to be a
major porting pain. But getting the run-time environment ironed out is
just plain (hard) work. Things where /bin/sh expects certain bash-isms.
Where paths have not been setup to the fullest all the way back into
./configure: like ${initrddir} => /etc/init.d versus /usr/local/etc/rc.d.
Probably plenty more like these.
To answer myself:
grep != grep
freetest# grep -P test *
grep: The -P option is not supported
:(
And only to match things like:
ceph-authtool kring --list|grep -P '^\tcaps '
Start looking for a mode that works could work on both
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 17:20, Gregory Farnum wrote: Installed the results: gmake install And looked at what it delivered: zfs diff And I have to be honest that I'm not really enjoying all the ceph-test stuff in my /usr/local/bin Would prefer it to go into something like: /usr/local/libexec/ceph/tests or /usr/local/share/ceph/tests Not sure if this is possible without disrupting the automated testing. As far as I know, none of what we do upstream relies on "make install" and I don't think it's very well-maintained. You could make some changes and submit a PR — if it does break something it should show up in the autobuilder bot. Well got that all compiled and installed. Fixed a startup problem in /usr/local/bin/ceph's python with an unknown error value. So that looks to run. Created a config, and acompanying directories. And now for the real work: Run: ceph-mon -i freetest -d --debug_mon 10 --cluster digiceph -c /etc/ceph/ceph.conf Which bombs out with: 2015-12-01 10:32:41.877243 804015000 0 ceph version 10.0.0-677-gd704c54 (d704c54b7923ef7265fa27018e9411d8deb463b3), process (unknown), pid 93896 2015-12-01 10:32:41.879339 804015000 -1 load dlopen(/usr/local/lib/ceph/erasure-code/libec_jerasure.so): /usr/local/lib/ceph/erasure-code/libec_jerasure.so: Undefined symbol "ceph_arch_neon" So of to find where ceph_arch_neon is, and why it seems not defined. Perhaps as simple as loading the shared libs?? --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 13:22, Mykola Golub wrote: On Tue, Dec 01, 2015 at 10:42:57AM +0100, Willem Jan Withagen wrote: On 30-11-2015 17:20, Gregory Farnum wrote: Installed the results: gmake install And looked at what it delivered: zfs diff And I have to be honest that I'm not really enjoying all the ceph-test stuff in my /usr/local/bin Would prefer it to go into something like: /usr/local/libexec/ceph/tests or /usr/local/share/ceph/tests Not sure if this is possible without disrupting the automated testing. As far as I know, none of what we do upstream relies on "make install" and I don't think it's very well-maintained. You could make some changes and submit a PR — if it does break something it should show up in the autobuilder bot. Well got that all compiled and installed. Fixed a startup problem in /usr/local/bin/ceph's python with an unknown error value. So that looks to run. Created a config, and acompanying directories. And now for the real work: Run: ceph-mon -i freetest -d --debug_mon 10 --cluster digiceph -c /etc/ceph/ceph.conf Which bombs out with: 2015-12-01 10:32:41.877243 804015000 0 ceph version 10.0.0-677-gd704c54 (d704c54b7923ef7265fa27018e9411d8deb463b3), process (unknown), pid 93896 2015-12-01 10:32:41.879339 804015000 -1 load dlopen(/usr/local/lib/ceph/erasure-code/libec_jerasure.so): /usr/local/lib/ceph/erasure-code/libec_jerasure.so: Undefined symbol "ceph_arch_neon" So of to find where ceph_arch_neon is, and why it seems not defined. Perhaps as simple as loading the shared libs?? You have to add -export-dynamic to LDFLAGS, something like in this patch: That one I missed... I guess I need to read more carefully, since lots of the remainder did not make sense. Mainly because I did not really want to start a dev cluster right away. So I'm aiming for 'gmake check' atm. --WjW https://github.com/trociny/ceph/commit/dcee0c0635d37f2b36257c55a3cc69d05b5afe5e#diff-ef3c0ccbdde56cca822801c6ef1d289aR79 Also, you don't have to install binaries just to test if they work. As I wrote previously: cd src ./vstart.sh It will start a dev cluster for you using binaries from the build dir. You can check if it runs with: ./ceph -s -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 14:21, Sage Weil wrote: The problem with all of the porting code in general is that it is doomed to break later on if we don't have (at least) ongoing build tests. In order for a FreeBSD or OSX port to continue working we need VMs that run either gitbuilder or a jenkins job or similar so that we can tell when it breaks. If someone is willing to run a VM somewhere to do this we can pretty easily stick it on the gitbuilder page at http://ceph.com/gitbuilder.cgi Hi Sage, Could you give some pointers as to where to start running the tests. I see a lot of "basic" tests to see if the platform is actually conformant. So before plunging into running ceph-mon and stuff, it would perhaps be better to actually run (parts of) the basic required tests.. Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 1-12-2015 14:30, Sage Weil wrote: On Tue, 1 Dec 2015, Willem Jan Withagen wrote: On 30-11-2015 14:21, Sage Weil wrote: The problem with all of the porting code in general is that it is doomed to break later on if we don't have (at least) ongoing build tests. In order for a FreeBSD or OSX port to continue working we need VMs that run either gitbuilder or a jenkins job or similar so that we can tell when it breaks. If someone is willing to run a VM somewhere to do this we can pretty easily stick it on the gitbuilder page at http://ceph.com/gitbuilder.cgi Hi Sage, Could you give some pointers as to where to start running the tests. I see a lot of "basic" tests to see if the platform is actually conformant. So before plunging into running ceph-mon and stuff, it would perhaps be better to actually run (parts of) the basic required tests.. I would start with 'make check' from src/... that's what we'd actually want the gitbuilder to do. I was running that at the moment Found the suggestion on the developers pages, in the manual section. Sort of hidden at the bottom. :) Did kill it in between, but now when I run it, it just only generates the report. So I just went make clean, which is rather too much... But could not really figure out the makefiles in test (yet) How do I reset the test results? --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 15:40, Willem Jan Withagen wrote: > On 30-11-2015 15:13, Mykola Golub wrote: >> On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote: >> >>>> git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git >>>> cd ceph >>>> ./install-deps.sh >>>> ./do_autogen.sh >>>> gmake >>>> cd src >>>> ./vstart.sh # start dev cluster >>>> ./ceph -s # check it works >>>> >>> >>> So what backend for the OSDs are you using here? >> >> The default one, which is FileStore. I have not done much testing >> though... >> > > Well, > Cherry-picked a few of you diffs. > Compilation is now slugging thru the tests in my tree. > Running gmake in serial mode, so it is slow with clang. Installed the results: gmake install And looked at what it delivered: zfs diff And I have to be honest that I'm not really enjoying all the ceph-test stuff in my /usr/local/bin Would prefer it to go into something like: /usr/local/libexec/ceph/tests or /usr/local/share/ceph/tests Not sure if this is possible without disrupting the automated testing. --WjW + /sbin/mount.fuse.ceph zfsroot/tmp M /tmp/ + /tmp/fses zfsroot/usr M /usr/local/sbin M /usr/local/bin M /usr/local/etc M /usr/local/include M /usr/local/lib M /usr/local/libexec M /usr/local/share M /usr/local/share/doc M /usr/local/lib/python2.7/site-packages M /usr/srcs/Ceph/src/ceph/src/.libs/libradosstriper.so.1 M /usr/srcs/Ceph/src/ceph/src/.libs/librbd.so.1 + /usr/local/share/ceph + /usr/local/share/ceph/known_hosts_drop.ceph.com + /usr/local/share/ceph/id_dsa_drop.ceph.com + /usr/local/share/ceph/id_dsa_drop.ceph.com.pub + /usr/local/lib/librados.so.2 + /usr/local/lib/librados.so + /usr/local/lib/librados.la + /usr/srcs/Ceph/src/ceph/src/.libs/libradosstriper.so.1T + /usr/local/lib/libradosstriper.so.1 + /usr/local/lib/libradosstriper.so + /usr/local/lib/libradosstriper.la + /usr/srcs/Ceph/src/ceph/src/.libs/librbd.so.1T + /usr/local/lib/librbd.so.1 + /usr/local/lib/librbd.so + /usr/local/lib/librbd.la + /usr/local/lib/libcephfs.so.1 + /usr/local/lib/libcephfs.so + /usr/local/lib/libcephfs.la + /usr/local/lib/librados.a + /usr/local/lib/libradosstriper.a + /usr/local/lib/librbd.a + /usr/local/lib/libcephfs.a + /usr/local/bin/ceph_test_ioctls + /usr/local/bin/ceph_erasure_code_benchmark + /usr/local/bin/ceph_erasure_code + /usr/local/bin/ceph_test_rados + /usr/local/bin/ceph_test_mutate + /usr/local/bin/ceph_smalliobench + /usr/local/bin/ceph_omapbench + /usr/local/bin/ceph_objectstore_bench + /usr/local/bin/ceph_multi_stress_watch + /usr/local/bin/ceph_test_cls_rbd + /usr/local/bin/ceph_test_cls_refcount + /usr/local/bin/ceph_test_cls_version + /usr/local/bin/ceph_test_cls_log + /usr/local/bin/ceph_test_cls_statelog + /usr/local/bin/ceph_test_cls_replica_log + /usr/local/bin/ceph_test_cls_lock + /usr/local/bin/ceph_test_cls_hello + /usr/local/bin/ceph_test_cls_numops + /usr/local/bin/ceph_test_cls_journal + /usr/local/bin/ceph_test_rados_api_cmd + /usr/local/bin/ceph_test_rados_api_io + /usr/local/bin/ceph_test_rados_api_c_write_operations + /usr/local/bin/ceph_test_rados_api_c_read_operations + /usr/local/bin/ceph_test_rados_api_aio + /usr/local/bin/ceph_test_rados_api_list + /usr/local/bin/ceph_test_rados_api_nlist + /usr/local/bin/ceph_test_rados_api_pool + /usr/local/bin/ceph_test_rados_api_stat + /usr/local/bin/ceph_test_rados_api_watch_notify + /usr/local/bin/ceph_test_rados_api_snapshots + /usr/local/bin/ceph_test_rados_api_cls + /usr/local/bin/ceph_test_rados_api_misc + /usr/local/bin/ceph_test_rados_api_tier + /usr/local/bin/ceph_test_rados_api_lock + /usr/local/bin/ceph_test_stress_watch + /usr/local/bin/ceph_smalliobenchrbd + /usr/local/bin/ceph_test_librbd + /usr/local/bin/ceph_test_librbd_api + /usr/local/bin/ceph_test_rados_striper_api_io + /usr/local/bin/ceph_test_rados_striper_api_aio + /usr/local/bin/ceph_test_rados_striper_api_striping + /usr/local/bin/ceph_test_libcephfs + /usr/local/bin/ceph_test_c_headers + /usr/local/bin/ceph_test_async_driver + /usr/local/bin/ceph_test_msgr + /usr/local/bin/ceph_streamtest + /usr/local/bin/ceph_test_trans + /usr/local/bin/ceph_test_mon_workloadgen + /usr/local/bin/ceph_test_mon_msg + /usr/local/bin/ceph_perf_objectstore + /usr/local/bin/ceph_perf_local + /usr/local/b
Re: Compiling for FreeBSD
On 30-11-2015 15:13, Mykola Golub wrote: > On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote: > >>> git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git >>> cd ceph >>> ./install-deps.sh >>> ./do_autogen.sh >>> gmake >>> cd src >>> ./vstart.sh # start dev cluster >>> ./ceph -s # check it works >>> >> >> So what backend for the OSDs are you using here? > > The default one, which is FileStore. I have not done much testing > though... > Seems we have passed the first hurdle... It compiles... Onto the next phase: Testing. Lets see what the developers site has to tell about that. --WjW chmod +x ceph-coverage.tmp chmod a-w ceph-coverage.tmp mv ceph-coverage.tmp ceph-coverage cd ./ceph-detect-init ; python setup.py build running build running build_py gmake[3]: Leaving directory '/usr/srcs/Ceph/src/ceph/src' gmake[2]: Leaving directory '/usr/srcs/Ceph/src/ceph/src' gmake[1]: Leaving directory '/usr/srcs/Ceph/src/ceph/src' Making all in man gmake[1]: Entering directory '/usr/srcs/Ceph/src/ceph/man' gmake[1]: Nothing to be done for 'all'. gmake[1]: Leaving directory '/usr/srcs/Ceph/src/ceph/man' Making all in doc gmake[1]: Entering directory '/usr/srcs/Ceph/src/ceph/doc' gmake[1]: Nothing to be done for 'all'. gmake[1]: Leaving directory '/usr/srcs/Ceph/src/ceph/doc' Making all in systemd gmake[1]: Entering directory '/usr/srcs/Ceph/src/ceph/systemd' gmake[1]: Nothing to be done for 'all'. gmake[1]: Leaving directory '/usr/srcs/Ceph/src/ceph/systemd' Making all in selinux gmake[1]: Entering directory '/usr/srcs/Ceph/src/ceph/selinux' gmake[1]: Nothing to be done for 'all'. gmake[1]: Leaving directory '/usr/srcs/Ceph/src/ceph/selinux' -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 07:58, Mykola Golub wrote: > On Mon, Nov 30, 2015 at 11:46:27AM +0800, Yan, Zheng wrote: >> On Mon, Nov 30, 2015 at 2:57 AM, Willem Jan Withagen <w...@digiware.nl> >> wrote: ... Hi Mykola, > I have a branch in my repo that contains patches to make compilation > on FreeBSD easier: > > https://github.com/trociny/ceph/commits/wip-freebsd Right, I'll and see what you've all got worked out. First get done with my daytime job that pays the rent. > The branch have not been rebased against master since March though, > still I hope to find time in future to update and pull some bits > upstream. > > Particularly, this patch contains packages dependencies list: > > https://github.com/trociny/ceph/commit/2307706461ae09922c087065a8b50a04a61159b1 Right, I had most of those already figured out, but some much less obvious. And the humor is on the first line... bash <> sh. In just about all linux oriented software that is one of the things to start with. FreePBX is also loaded with those. I've sort of given up on this one, resistance is futile. And I install bash in /bin. > And this one configuration options I used > > https://github.com/trociny/ceph/commit/dcee0c0635d37f2b36257c55a3cc69d05b5afe5e > > I have seen several commits since that time in master aimed to improve > FreeBSD compilation, so I suppose some of my patches are not needed > any more. > > Still, if you experince issues building upstream Ceph on FreeBSD, and > just want to try it on FreeBSD, you could try my branch: > > git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git > cd ceph > ./install-deps.sh > ./do_autogen.sh > gmake > cd src > ./vstart.sh # start dev cluster > ./ceph -s # check it works > So what backend for the OSDs are you using here? --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 14:21, Sage Weil wrote: > The problem with all of the porting code in general is that it is doomed > to break later on if we don't have (at least) ongoing build tests. In > order for a FreeBSD or OSX port to continue working we need VMs that run > either gitbuilder or a jenkins job or similar so that we can tell when it > breaks. > > If someone is willing to run a VM somewhere to do this we can pretty > easily stick it on the gitbuilder page at > > http://ceph.com/gitbuilder.cgi Hi Sage, Cool page that gitbuilder Would be nice to have a FreeBSD builder in there as well. :) Once I get things up and running, I will be able to supply either VMs and/or actual hardware to do building and testing. My personal problem is that I'm a longtime FreeBSD user (since 1993) and now I'm sort of forced into (the) other OS. Because we like Ceph. So we are building currently on Linux, but would like to have a FreeBSD possibility as well. But first I need to get the code to compile, and then actually run. Long term goal is to use ZFS as basis, since this is a rock solid FS on FreeBSD. And then integrate it with another nice FreeBSD thingy: bhyve. Now I'm taking small baby steps at the moment, and do have other chores as well. So progress might be slow, but I think I found some of the issues I did not get to yet in the git of Mykola. Thanx for the feedback. Regards, --Willem Jan -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 30-11-2015 15:13, Mykola Golub wrote: > On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote: > >>> git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git >>> cd ceph >>> ./install-deps.sh >>> ./do_autogen.sh >>> gmake >>> cd src >>> ./vstart.sh # start dev cluster >>> ./ceph -s # check it works >>> >> >> So what backend for the OSDs are you using here? > > The default one, which is FileStore. I have not done much testing > though... > Well, Cherry-picked a few of you diffs. Compilation is now slugging thru the tests in my tree. Running gmake in serial mode, so it is slow with clang. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Compiling for FreeBSD
Hi, Not unlike many others running FreeBSD I'd like to see if I/we can get Ceph to build and run on FreeBSD. If not all components than at least certain components. With compilation I do get quite some way, even with the CLANG compiler. But I run into obvious part where Linux goes a different direction from what is available on FreeBSD. If I google one of the reports I ran into, I get at: http://lists.ceph.com/pipermail/ceph-commit-ceph.com/2013-November/005812.html Which sort of suggests that some of the code for FreeBSD has again been purged from the tree... Is that to remove FreeBSD completely from the tree? Or just because that code did not work? Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling for FreeBSD
On 29-11-2015 19:08, Haomai Wang wrote: > I guess we still expect FreeBSD support, which version do you test to > compile? I'd like to help to make bsd work :-) I considered it is best to develop against HEAD aka: 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291381: Sat Nov 28 14:22:54 CET 2015 I'm also training configure the use as much of CLANG as possible. I would guess that by the time we get anything worth mentioning 11.0 will be released of close to release. Note that the release date for 11.0 is july 2016 --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
