* Re: Compiling for FreeBSD
2015-11-30 13:21 ` Sage Weil
@ 2015-11-30 13:54 ` Willem Jan Withagen
2015-12-01 11:08 ` Willem Jan Withagen
` (3 subsequent siblings)
4 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-11-30 13:54 UTC (permalink / raw)
To: Sage Weil, Mykola Golub; +Cc: Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-11-30 13:21 ` Sage Weil
2015-11-30 13:54 ` Willem Jan Withagen
@ 2015-12-01 11:08 ` Willem Jan Withagen
2015-12-01 13:30 ` Sage Weil
2016-01-16 12:56 ` Compiling for FreeBSD Willem Jan Withagen
2015-12-10 15:03 ` Compiling for FreeBSD, trouble in buffer.c Willem Jan Withagen
` (2 subsequent siblings)
4 siblings, 2 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 11:08 UTC (permalink / raw)
To: Sage Weil, Mykola Golub; +Cc: Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-12-01 11:08 ` Willem Jan Withagen
@ 2015-12-01 13:30 ` Sage Weil
2015-12-01 13:42 ` Willem Jan Withagen
2016-01-16 12:56 ` Compiling for FreeBSD Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Sage Weil @ 2015-12-01 13:30 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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.
sage
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 13:30 ` Sage Weil
@ 2015-12-01 13:42 ` Willem Jan Withagen
2015-12-01 14:35 ` Sage Weil
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 13:42 UTC (permalink / raw)
To: Sage Weil; +Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 13:42 ` Willem Jan Withagen
@ 2015-12-01 14:35 ` Sage Weil
2015-12-01 16:24 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Sage Weil @ 2015-12-01 14:35 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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).
At least, that's the case on Linux.. maybe the (auto)tools are a bit
different on *BSD?
sage
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 14:35 ` Sage Weil
@ 2015-12-01 16:24 ` Willem Jan Withagen
2015-12-01 17:22 ` Alan Somers
2015-12-01 18:51 ` Willem Jan Withagen
0 siblings, 2 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 16:24 UTC (permalink / raw)
To: Sage Weil; +Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-12-01 16:24 ` Willem Jan Withagen
@ 2015-12-01 17:22 ` Alan Somers
2015-12-01 18:08 ` Willem Jan Withagen
2015-12-01 18:51 ` Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Alan Somers @ 2015-12-01 17:22 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Sage Weil, Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
On Tue, Dec 1, 2015 at 9:24 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> 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
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/
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
-Alan
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-12-01 17:22 ` Alan Somers
@ 2015-12-01 18:08 ` Willem Jan Withagen
2015-12-01 18:21 ` Alan Somers
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 18:08 UTC (permalink / raw)
To: Alan Somers
Cc: Sage Weil, Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-12-01 18:08 ` Willem Jan Withagen
@ 2015-12-01 18:21 ` Alan Somers
2015-12-01 18:31 ` Willem Jan Withagen
2015-12-01 18:36 ` Sage Weil
0 siblings, 2 replies; 61+ messages in thread
From: Alan Somers @ 2015-12-01 18:21 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Sage Weil, Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <wjw@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
-Alan
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 18:21 ` Alan Somers
@ 2015-12-01 18:31 ` Willem Jan Withagen
2015-12-01 18:36 ` Sage Weil
1 sibling, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 18:31 UTC (permalink / raw)
To: Alan Somers
Cc: Sage Weil, Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
On 1-12-2015 19:21, Alan Somers wrote:
> On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 18:21 ` Alan Somers
2015-12-01 18:31 ` Willem Jan Withagen
@ 2015-12-01 18:36 ` Sage Weil
2015-12-01 18:43 ` Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Sage Weil @ 2015-12-01 18:36 UTC (permalink / raw)
To: Alan Somers
Cc: Willem Jan Withagen, Mykola Golub, Yan, Zheng, Haomai Wang,
Ceph Development
On Tue, 1 Dec 2015, Alan Somers wrote:
> On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen <wjw@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
?
sage
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 18:36 ` Sage Weil
@ 2015-12-01 18:43 ` Willem Jan Withagen
2015-12-02 14:13 ` Yan, Zheng
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 18:43 UTC (permalink / raw)
To: Sage Weil, Alan Somers
Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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 <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 18:43 ` Willem Jan Withagen
@ 2015-12-02 14:13 ` Yan, Zheng
2015-12-02 20:52 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Yan, Zheng @ 2015-12-02 14:13 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Sage Weil, Alan Somers, Mykola Golub, Haomai Wang, Ceph Development
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.
Regards
Yan. Zheng
On Wed, Dec 2, 2015 at 2:43 AM, Willem Jan Withagen <wjw@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 <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-02 14:13 ` Yan, Zheng
@ 2015-12-02 20:52 ` Willem Jan Withagen
2015-12-03 0:27 ` Yan, Zheng
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-02 20:52 UTC (permalink / raw)
To: Yan, Zheng
Cc: Sage Weil, Alan Somers, Mykola Golub, Haomai Wang, Ceph Development
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 <wjw@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 <wjw@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-02 20:52 ` Willem Jan Withagen
@ 2015-12-03 0:27 ` Yan, Zheng
2015-12-04 18:30 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Yan, Zheng @ 2015-12-03 0:27 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Sage Weil, Alan Somers, Mykola Golub, Haomai Wang, Ceph Development
On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> 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?
not disable. Currently ceph uses boost uuid implementation. so no need
to link to libuuid.
>
> 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 <wjw@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 <wjw@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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-03 0:27 ` Yan, Zheng
@ 2015-12-04 18:30 ` Willem Jan Withagen
2015-12-04 18:44 ` Gregory Farnum
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-04 18:30 UTC (permalink / raw)
To: Yan, Zheng
Cc: Sage Weil, Alan Somers, Mykola Golub, Haomai Wang, Ceph Development
On 3-12-2015 01:27, Yan, Zheng wrote:
> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-04 18:30 ` Willem Jan Withagen
@ 2015-12-04 18:44 ` Gregory Farnum
2015-12-04 20:11 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Gregory Farnum @ 2015-12-04 18:44 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Yan, Zheng, Sage Weil, Alan Somers, Mykola Golub, Haomai Wang,
Ceph Development
On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> On 3-12-2015 01:27, Yan, Zheng wrote:
>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <wjw@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.
-Greg
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-04 18:44 ` Gregory Farnum
@ 2015-12-04 20:11 ` Willem Jan Withagen
2015-12-08 9:59 ` Willem Jan Withagen
2015-12-08 10:04 ` Willem Jan Withagen
0 siblings, 2 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-04 20:11 UTC (permalink / raw)
To: Gregory Farnum
Cc: Yan, Zheng, Sage Weil, Alan Somers, Mykola Golub, Haomai Wang,
Ceph Development
On 4-12-2015 19:44, Gregory Farnum wrote:
> On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> On 3-12-2015 01:27, Yan, Zheng wrote:
>>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-04 20:11 ` Willem Jan Withagen
@ 2015-12-08 9:59 ` Willem Jan Withagen
2015-12-08 10:04 ` Willem Jan Withagen
1 sibling, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-08 9:59 UTC (permalink / raw)
To: Gregory Farnum
Cc: Yan, Zheng, Sage Weil, Alan Somers, Mykola Golub, Haomai Wang,
Ceph Development
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 <wjw@digiware.nl> wrote:
>>> On 3-12-2015 01:27, Yan, Zheng wrote:
>>>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen <wjw@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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-04 20:11 ` Willem Jan Withagen
2015-12-08 9:59 ` Willem Jan Withagen
@ 2015-12-08 10:04 ` Willem Jan Withagen
2015-12-08 12:36 ` Mykola Golub
1 sibling, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-08 10:04 UTC (permalink / raw)
To: Gregory Farnum
Cc: Yan, Zheng, Sage Weil, Alan Somers, Mykola Golub, Haomai Wang,
Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-08 10:04 ` Willem Jan Withagen
@ 2015-12-08 12:36 ` Mykola Golub
2015-12-08 15:59 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Mykola Golub @ 2015-12-08 12:36 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Gregory Farnum, Yan, Zheng, Sage Weil, Alan Somers, Haomai Wang,
Ceph Development
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.
--
Mykola Golub
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-08 12:36 ` Mykola Golub
@ 2015-12-08 15:59 ` Willem Jan Withagen
0 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-08 15:59 UTC (permalink / raw)
To: Mykola Golub
Cc: Gregory Farnum, Yan, Zheng, Sage Weil, Alan Somers, Haomai Wang,
Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 16:24 ` Willem Jan Withagen
2015-12-01 17:22 ` Alan Somers
@ 2015-12-01 18:51 ` Willem Jan Withagen
2015-12-02 21:10 ` Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-01 18:51 UTC (permalink / raw)
To: Sage Weil; +Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD
2015-12-01 18:51 ` Willem Jan Withagen
@ 2015-12-02 21:10 ` Willem Jan Withagen
2015-12-02 22:47 ` Compiling for FreeBSD, missing rbd Willem Jan Withagen
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
0 siblings, 2 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-02 21:10 UTC (permalink / raw)
To: Sage Weil; +Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, missing rbd
2015-12-02 21:10 ` Willem Jan Withagen
@ 2015-12-02 22:47 ` Willem Jan Withagen
2015-12-03 12:34 ` Mykola Golub
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-02 22:47 UTC (permalink / raw)
To: Sage Weil; +Cc: Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, missing rbd
2015-12-02 22:47 ` Compiling for FreeBSD, missing rbd Willem Jan Withagen
@ 2015-12-03 12:34 ` Mykola Golub
2015-12-03 13:27 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Mykola Golub @ 2015-12-03 12:34 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Sage Weil, Ceph Development
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.
--
Mykola Golub
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, missing rbd
2015-12-03 12:34 ` Mykola Golub
@ 2015-12-03 13:27 ` Willem Jan Withagen
0 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-03 13:27 UTC (permalink / raw)
To: Mykola Golub; +Cc: Sage Weil, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, runtimes for seperate tests.
2015-12-02 21:10 ` Willem Jan Withagen
2015-12-02 22:47 ` Compiling for FreeBSD, missing rbd Willem Jan Withagen
@ 2015-12-03 9:50 ` Willem Jan Withagen
2015-12-03 14:12 ` Willem Jan Withagen
` (2 more replies)
1 sibling, 3 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-03 9:50 UTC (permalink / raw)
To: Sage Weil, Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, runtimes for seperate tests.
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
@ 2015-12-03 14:12 ` Willem Jan Withagen
2015-12-03 21:06 ` Gregory Farnum
2015-12-05 12:56 ` Compiling for FreeBSD, Clang refuses to compile a test Willem Jan Withagen
2 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-03 14:12 UTC (permalink / raw)
To: Sage Weil, Ceph Development
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
============================================================================
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, runtimes for seperate tests.
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
2015-12-03 14:12 ` Willem Jan Withagen
@ 2015-12-03 21:06 ` Gregory Farnum
2015-12-05 12:56 ` Compiling for FreeBSD, Clang refuses to compile a test Willem Jan Withagen
2 siblings, 0 replies; 61+ messages in thread
From: Gregory Farnum @ 2015-12-03 21:06 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Sage Weil, Ceph Development
On Thu, Dec 3, 2015 at 1:50 AM, Willem Jan Withagen <wjw@digiware.nl> 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....
Well, 12 hours is ludicrous, but a few of the tests really do take 20
minutes — I think the shec EC one? I don't have any better info than
that for you, though. I mostly just wait on the gitbuilders.
-Greg
>
> 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 majordomo@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
2015-12-03 14:12 ` Willem Jan Withagen
2015-12-03 21:06 ` Gregory Farnum
@ 2015-12-05 12:56 ` Willem Jan Withagen
2015-12-05 13:02 ` Xinze Chi (信泽)
2 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-05 12:56 UTC (permalink / raw)
To: Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-05 12:56 ` Compiling for FreeBSD, Clang refuses to compile a test Willem Jan Withagen
@ 2015-12-05 13:02 ` Xinze Chi (信泽)
2015-12-07 21:44 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Xinze Chi (信泽) @ 2015-12-05 13:02 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Ceph Development
I think "const int k = 12; const int m = 4" would pass the compile?
2015-12-05 20:56 GMT+08:00 Willem Jan Withagen <wjw@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
>
> --WjW
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Xinze Chi
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-05 13:02 ` Xinze Chi (信泽)
@ 2015-12-07 21:44 ` Willem Jan Withagen
2015-12-07 22:19 ` Michal Jarzabek
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-07 21:44 UTC (permalink / raw)
To: Xinze Chi (信泽); +Cc: Ceph Development
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 <wjw@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-07 21:44 ` Willem Jan Withagen
@ 2015-12-07 22:19 ` Michal Jarzabek
2015-12-08 0:29 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Michal Jarzabek @ 2015-12-07 22:19 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Xinze Chi (信泽), Ceph Development
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.
Thanks,
Michal
On Mon, Dec 7, 2015 at 9:44 PM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> 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 <wjw@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 majordomo@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-07 22:19 ` Michal Jarzabek
@ 2015-12-08 0:29 ` Willem Jan Withagen
2015-12-08 8:48 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-08 0:29 UTC (permalink / raw)
To: Michal Jarzabek; +Cc: Xinze Chi (信泽), Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Clang refuses to compile a test
2015-12-08 0:29 ` Willem Jan Withagen
@ 2015-12-08 8:48 ` Willem Jan Withagen
0 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-08 8:48 UTC (permalink / raw)
To: Michal Jarzabek; +Cc: Xinze Chi (信泽), Ceph Development
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-12-01 11:08 ` Willem Jan Withagen
2015-12-01 13:30 ` Sage Weil
@ 2016-01-16 12:56 ` Willem Jan Withagen
1 sibling, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2016-01-16 12:56 UTC (permalink / raw)
To: Sage Weil, Mykola Golub; +Cc: Yan, Zheng, Haomai Wang, Ceph Development
On 1-12-2015 12:08, 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
>
I have build a pull request that includes the changes to get the
automake tools do a decent job on the current master.
https://github.com/ceph/ceph/pull/7239
But then I tried building a second WIP with changes to the {cc,} code,
but then I end up with a WIP tree with a complete string of other
commits in between. Which is certainly not the intention.
https://github.com/wjwithagen/ceph/tree/wip-wjw-freebsd-compilechanges
The next one WIP would be wip-wjw-freebsd-testchanges which got me as
far as 110 tests successfully completed.
I see to be able to mess up the integration of the ceph/master into my
fork and my WIPs...
Is there a way to easily repair this? Or just
save the diffs
scrap the whole fork
make a new fork and WIP
push
Once I get this straight I promise to write this down as simple howto,
on then how to keep up in this fork and WIP with ceph/master
Thanx,
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, trouble in buffer.c
2015-11-30 13:21 ` Sage Weil
2015-11-30 13:54 ` Willem Jan Withagen
2015-12-01 11:08 ` Willem Jan Withagen
@ 2015-12-10 15:03 ` Willem Jan Withagen
2015-12-11 9:56 ` Willem Jan Withagen
2016-01-15 10:52 ` Compiling for FreeBSD, Bluestore requires AIO Willem Jan Withagen
2016-05-28 0:15 ` Compiling for FreeBSD Willem Jan Withagen
4 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-10 15:03 UTC (permalink / raw)
To: Sage Weil; +Cc: Ceph Development
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<ptr>::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
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, trouble in buffer.c
2015-12-10 15:03 ` Compiling for FreeBSD, trouble in buffer.c Willem Jan Withagen
@ 2015-12-11 9:56 ` Willem Jan Withagen
0 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2015-12-11 9:56 UTC (permalink / raw)
To: Sage Weil; +Cc: Ceph Development
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<ptr>::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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Bluestore requires AIO
2015-11-30 13:21 ` Sage Weil
` (2 preceding siblings ...)
2015-12-10 15:03 ` Compiling for FreeBSD, trouble in buffer.c Willem Jan Withagen
@ 2016-01-15 10:52 ` Willem Jan Withagen
2016-01-15 11:21 ` Willem Jan Withagen
2016-01-15 17:30 ` Sage Weil
2016-05-28 0:15 ` Compiling for FreeBSD Willem Jan Withagen
4 siblings, 2 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2016-01-15 10:52 UTC (permalink / raw)
To: Sage Weil, Mykola Golub; +Cc: Yan, Zheng, Haomai Wang, Ceph Development
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
Well this is real nice case of such an incident.
I'm verifying my changes to the C/C++ code, after having forwarded to HEAD.
And now I get bluestore complaining that it requires AIO.
Something I've thusfar excluded in the build.
Does Bluestore really require AIO??
FreeBSD does have AIO, but to take simple steps one at the time, I
excluded it
with configure. Mainly because it bombs at compile time. Probably due to
different include files, or function nameing.....
So, in order of preference:
- Can I disable AIO for Bluestore
- Can I disable bluestore being build?
Thanx,
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Bluestore requires AIO
2016-01-15 10:52 ` Compiling for FreeBSD, Bluestore requires AIO Willem Jan Withagen
@ 2016-01-15 11:21 ` Willem Jan Withagen
2016-01-15 17:30 ` Sage Weil
1 sibling, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2016-01-15 11:21 UTC (permalink / raw)
To: Sage Weil, Mykola Golub; +Cc: Yan, Zheng, Haomai Wang, Ceph Development
On 15-1-2016 11:52, 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
>
> Well this is real nice case of such an incident.
>
> I'm verifying my changes to the C/C++ code, after having forwarded to HEAD.
> And now I get bluestore complaining that it requires AIO.
> Something I've thusfar excluded in the build.
>
> Does Bluestore really require AIO??
> FreeBSD does have AIO, but to take simple steps one at the time, I
> excluded it
> with configure. Mainly because it bombs at compile time. Probably due to
> different include files, or function nameing.....
>
> So, in order of preference:
> - Can I disable AIO for Bluestore
> - Can I disable bluestore being build?
Spoke a bit too soon.
FreeBSD has AIO, loadable as kernelmodule. with the following systemcalls.
aio_cancel(2), aio_error(2), aio_read(2), aio_return(2), aio_suspend(2),
aio_waitcomplete(2), aio_write(2), lio_listio(2)
But libaio is based on:
/* Actual syscalls */
extern int io_setup(int maxevents, io_context_t *ctxp);
extern int io_destroy(io_context_t ctx);
extern int io_submit(io_context_t ctx, long nr, struct iocb *ios[]);
extern int io_cancel(io_context_t ctx, struct iocb *iocb, struct
io_event *evt);
extern int io_getevents(io_context_t ctx_id, long min_nr, long nr,
struct io_event *events, struct timespec *timeout);
So glueing that together is not just fixing some include files, and or
fetching
some shim-library that is lurking out in /usr/ports...
And for the time being I would like to skip over the libaio hurdle.
Is that possible?
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Compiling for FreeBSD, Bluestore requires AIO
2016-01-15 10:52 ` Compiling for FreeBSD, Bluestore requires AIO Willem Jan Withagen
2016-01-15 11:21 ` Willem Jan Withagen
@ 2016-01-15 17:30 ` Sage Weil
2016-01-15 18:34 ` Willem Jan Withagen
1 sibling, 1 reply; 61+ messages in thread
From: Sage Weil @ 2016-01-15 17:30 UTC (permalink / raw)
To: Willem Jan Withagen
Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
On Fri, 15 Jan 2016, 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
>
> Well this is real nice case of such an incident.
>
> I'm verifying my changes to the C/C++ code, after having forwarded to HEAD.
> And now I get bluestore complaining that it requires AIO.
> Something I've thusfar excluded in the build.
>
> Does Bluestore really require AIO??
> FreeBSD does have AIO, but to take simple steps one at the time, I excluded it
> with configure. Mainly because it bombs at compile time. Probably due to
> different include files, or function nameing.....
>
> So, in order of preference:
> - Can I disable AIO for Bluestore
> - Can I disable bluestore being build?
AIO is currently required. The good news is it is confined (mostly) to
os/bluestore/BlockDevice.h, so providing an alternative (or non-aio)
implementaiton shouldnt' be difficult.. in fact it is mostly there.
sage
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Bluestore requires AIO
2016-01-15 17:30 ` Sage Weil
@ 2016-01-15 18:34 ` Willem Jan Withagen
2016-01-18 9:54 ` Mykola Golub
0 siblings, 1 reply; 61+ messages in thread
From: Willem Jan Withagen @ 2016-01-15 18:34 UTC (permalink / raw)
To: Sage Weil; +Cc: Mykola Golub, Yan, Zheng, Haomai Wang, Ceph Development
On 15-1-2016 18:30, Sage Weil wrote:
> On Fri, 15 Jan 2016, 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
>>
>> Well this is real nice case of such an incident.
>>
>> I'm verifying my changes to the C/C++ code, after having forwarded to HEAD.
>> And now I get bluestore complaining that it requires AIO.
>> Something I've thusfar excluded in the build.
>>
>> Does Bluestore really require AIO??
>> FreeBSD does have AIO, but to take simple steps one at the time, I excluded it
>> with configure. Mainly because it bombs at compile time. Probably due to
>> different include files, or function nameing.....
>>
>> So, in order of preference:
>> - Can I disable AIO for Bluestore
>> - Can I disable bluestore being build?
>
> AIO is currently required. The good news is it is confined (mostly) to
> os/bluestore/BlockDevice.h, so providing an alternative (or non-aio)
> implementaiton shouldnt' be difficult.. in fact it is mostly there.
Hi Sage,
ATM I've excluded the building of Bluestore, not really knowing how hard
that is going to bite me in run the tests.
But I guess we're going to find out the hard way. 8D
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Bluestore requires AIO
2016-01-15 18:34 ` Willem Jan Withagen
@ 2016-01-18 9:54 ` Mykola Golub
2016-01-18 10:05 ` Willem Jan Withagen
0 siblings, 1 reply; 61+ messages in thread
From: Mykola Golub @ 2016-01-18 9:54 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Sage Weil, Yan, Zheng, Haomai Wang, Ceph Development
On Fri, Jan 15, 2016 at 07:34:29PM +0100, Willem Jan Withagen wrote:
> ATM I've excluded the building of Bluestore, not really knowing how hard
> that is going to bite me in run the tests.
It looks like you have figured out how to exclude building Bluestore,
but just in case, I have the following PR open, that do the same:
https://github.com/ceph/ceph/pull/7169
--
Mykola Golub
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD, Bluestore requires AIO
2016-01-18 9:54 ` Mykola Golub
@ 2016-01-18 10:05 ` Willem Jan Withagen
0 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2016-01-18 10:05 UTC (permalink / raw)
To: Mykola Golub; +Cc: Sage Weil, Yan, Zheng, Haomai Wang, Ceph Development
On 18-1-2016 10:54, Mykola Golub wrote:
> On Fri, Jan 15, 2016 at 07:34:29PM +0100, Willem Jan Withagen wrote:
>
>> ATM I've excluded the building of Bluestore, not really knowing how hard
>> that is going to bite me in run the tests.
>
> It looks like you have figured out how to exclude building Bluestore,
> but just in case, I have the following PR open, that do the same:
>
> https://github.com/ceph/ceph/pull/7169
>
I'd say: lgtm.... :)
The one thing to debate is to not make it depend on HAVE_LIBAIO, but
make it depend on a new configflag: WITH_BLUESTORE.
That even allows to include LIBAIO for the old stuff, and still run
without BlueStore.
And I patched configure.ac for that:
194,201d193
< # bluestore?
< AC_ARG_WITH([bluestore],
< [AS_HELP_STRING([--with-bluestore], [build bluestore files])],
< [],
< [with_bluestore=yes])
< AM_CONDITIONAL(WITH_BLUESTORE, test "$with_bluestore" = "yes")
< #AS_IF([test "$with_bluestore" = "yes"],[AC_DEFINE([WITH_BLUESTORE])])
<
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Compiling for FreeBSD
2015-11-30 13:21 ` Sage Weil
` (3 preceding siblings ...)
2016-01-15 10:52 ` Compiling for FreeBSD, Bluestore requires AIO Willem Jan Withagen
@ 2016-05-28 0:15 ` Willem Jan Withagen
4 siblings, 0 replies; 61+ messages in thread
From: Willem Jan Withagen @ 2016-05-28 0:15 UTC (permalink / raw)
To: Sage Weil; +Cc: Ceph Development
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,
Just a bit of victory after 6 months.
I'm not yet there by far, but I've just passed the mark of only one test
not working (the osd-markdown.sh one) and all other tests that I think
that are passable have now passed.
And that all against a tree that is rather recent.
osd-markdown is a test that is rather hard to follow, analyse, debug...
Which starts with the fact that I cannot find any docs on the parameters
that are being manipulated.
Asked the author, but got no response.
So I'm very tempted to execlude that test for the time being.
And I'm hoping that you can merge the compiletime #9178 wip soon, and I
can begin with the next set of commit to merge the testing work.
Thanx,
--WjW
^ permalink raw reply [flat|nested] 61+ messages in thread