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
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 start
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
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
g 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 benea
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
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.
> 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.
>
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
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,
are, 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
ered.
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
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").
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) ||
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
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
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
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
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> wro
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
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 sn
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
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
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:
&g
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 boos
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 minu
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
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
>>
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: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.
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
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
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...
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,
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
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
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:
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
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
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
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
>>
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
>&g
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 compila
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
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
>&g
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
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
47 matches
Mail list logo
