I'm not sure about the behavior of the function call rados_read_op_operate.
I'm hoping someone on this list can clarify and confirm that what I'm seeing is
expected behavior.
When I was first looking at this call I assumed that if one created a
rados_read_op_t (shortened as "op" later) and populated it with "steps" you'd
be able to call rados_read_op_operate with the op on more than one different
object. However, this does not seem to be the case. When I call
rados_read_op_operate a second time, the function returns but the items passed
in to the "step" calls do not change, unlike the first time the function is
called.
I have attached a C file that tries to demonstrate what I mean. The function
print_one_omap works as expected when called on two times on different objects.
The function print_two_omaps is passed two objects to read but only data for
the first is printed. (I also try to dump data but I was originally testing
with omaps only - thus the function names. Also please excuse and bad C code,
I don't usually write in C but wanted to confirm this behavior occurred when
using the C api.)
What I'd like to ask is if this is intended behavior. If not, I'll be happy to
file a bug, but from the code I skimmed and the function doc comments, its not
clear to me what is supposed to happen.
If anyone on this list can shed some light on this I'd greatly appreciate it.
--John M.
Hi,
Since we are adding build targets in github,
I have a question/favour to ask....
Would it be possible to also compile the sources with Clang.
As far as I'm concerned it does not have to be a blocker to get a PR
merged. But it would at least signal that there could be something
wrong with the PR, and it would be appreciated if the submitter
looks into the errors Clang reports.
My FreeBSD ports depend on Clang compilation and I now spent a big
part of the free time during the weekend fixing errors that Clang
trips over. Not leaving much time to actually do development work.
Clang is available on Linux as well, so it would not even have to
be a jenkins setup running on FreeBSD. Perhaps even better so, since
there are also FreeBSD incompatabilities that would be hard for
non-FreeBSDers to fix.
In the process it just might catch a possible bug, because Clang
sees life different from GCC.
Like I said: it is a favour to ask.
Thanx,
--WjW
Hi,
Thanks, I have Vlads patches as he kindly emailed them to me and have been starting to add them to alpine to get 32bit working here (currently not building):
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14888 <https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14888>
Vlad says he only applies the “arm32bit” prefix patches on armv7, he is working on merge requests to ceph also.
So it needs a way to detect 64/32bit in cmake or I saw a way with <cstdint> that is portable for applying the changes with "#ifdef” for 32bit only fixes that are not needed for 64bit.
Thanks,
Duncan
> On 24 Nov 2020, at 09:22, Anthony Davies <anthony.t.davies(a)gmail.com> wrote:
>
> Hi All,
>
> I had a similar idea to Vlad here but using the Olimex Lime2 as a platform, great minds think alike. My interest was mainly to use it with Rook for my low power kubernetes cluster.
>
> The last successful build I had running using Rook-ceph was 15.2.0, I doubled my kids around that time (1 to 2) and time disappeared.
>
> Having said that I had an issue #44197 <https://tracker.ceph.com/issues/44197> which Brad was planning to take a look at before he had a shift in priorities.
>
> I would love to see this up and working but have very little time to spend on it at the moment unfortunately, sounds like Vlad is more a dev then I am and can contribute PRs which I struggle with when it comes to C.
>
> Armv7 is a subset of armv8 and so any armv8 architecture can be used to compile, I personally used a 32 bit armv7 alpine image on high powered armv8 infrastructure.
>
> Vlad, I was using cloud.drone.io <http://cloud.drone.io/> to automate my builds, that may be an option for you also? They offer it free for open source projects.
>
> Happy to help out however I can with the limited time I have.
>
> Cheers,
>
> Tony
>
> On Tue, 24 Nov 2020 at 19:50, kefu chai <tchaikov(a)gmail.com <mailto:tchaikov@gmail.com>> wrote:
> hi Duncan and Vladimir,
>
> we don't have the hardware or dedicated resource for supporting armv7,
> i586, i686 or other 32bits architectures. but patches enabling us to
> support more architectures are always welcomed.
>
> cypress is only used for testing the dashboard. would be better if we
> could disable it conditionally based on platform / archs.
>
> +Tony Davies. as he's been testing Ceph on armv7 and aarch64 recently.
>
> On Mon, Nov 23, 2020 at 8:33 PM Duncan Bellamy <a.16bit.sysop(a)icloud.com <mailto:a.16bit.sysop@icloud.com>> wrote:
> >
> > Yes please, if you could email me as well as PRs I can see if I can get it to build for Alpine Linux.
> >
> > On 23 Nov 2020, at 12:20, Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> >
> > I have checked their patches and they are just not enough of getting everything up and running. They have patched two files which I patched as well but I also patched number of other files which are vital for correct operation. I'll do PRs soon or if you'd like I can email my patches directly.
> >
> > On 23/11/20 11:09 pm, Duncan Bellamy wrote:
> >
> > Thanks for that, ubuntu has it building for all arches, they have patches for 32bit and arm in the patches directory here:
> >
> > http://archive.ubuntu.com/ubuntu/pool/main/c/ceph/ceph_15.2.5-0ubuntu1.1.de… <http://archive.ubuntu.com/ubuntu/pool/main/c/ceph/ceph_15.2.5-0ubuntu1.1.de…>
> >
> >
> > On 23 Nov 2020, at 08:48, Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> >
> > I doubt that Cypress will build necessary stuff. Much faster:
> >
> > diff -uNr ceph-15.2.4/src/pybind/mgr/dashboard/frontend/package.json ceph-15.2.4-arm32_fix/src/pybind/mgr/dashboard/frontend/package.json
> > --- ceph-15.2.4/src/pybind/mgr/dashboard/frontend/package.json 2020-07-01 01:10:51.000000000 +0930
> > +++ ceph-15.2.4-arm32_fix/src/pybind/mgr/dashboard/frontend/package.json 2020-11-21 22:11:16.065796889 +1030
> > @@ -122,7 +122,6 @@
> > "@types/node": "12.12.34",
> > "@types/simplebar": "5.1.1",
> > "codelyzer": "5.2.2",
> > - "cypress": "4.4.0",
> > "html-linter": "1.1.1",
> > "htmllint-cli": "0.0.7",
> > "jest": "25.2.4",
> >
> >
> > On 23/11/20 7:37 pm, Duncan Bellamy wrote:
> >
> > Thanks for the info, I have opened an issue about it on cypress github:
> > https://github.com/cypress-io/cypress/issues/9272 <https://github.com/cypress-io/cypress/issues/9272>
> >
> > I don’t think the alpine build is running the test suite, cypress is installed and for the test step it does a cd into the build directory and runs “ctest” but looking at the build logs and searching for “ctest” returns 0 results.
> >
> > Duncan
> >
> > On 22 Nov 2020, at 23:18, Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> >
> > There no cypress for ARM 32 bit at all. As it is used just for testing I have removed it from package.json and then dropped relevant test to avoid test failure. Not the best solution but because I do build 64 bits as well I can sleep relatively easy knowing that it should work. Node is used to create mgr frontend and it should generate pretty much the same JS regardless of architecture.
> >
> > Explicit use of cypress also tells me that 32 bit support was dropped by Ceph silently. But I can say that after some patching ceph does pass full test suite on armv7l. I will provide them as PRs soon - hopefully they will be accepted and Ceph will run on 32 bits again.
> >
> > On 23 November 2020 4:01:18 am AEDT, Duncan Bellamy <a.16bit.sysop(a)icloud.com <mailto:a.16bit.sysop@icloud.com>> wrote:
> > I have been updating the Alpine Linux version to 15.2.6 and it fails on armv7 and x86 because cypress install fails with not found, how did you get cypress to work on arm 32bit?
> >
> > Duncan
> >
> > On 22 Nov 2020, at 08:49, Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> >
> >
> > Yeah, that's exactly because of this document I am kinda wondering. This document is latest dev and thus one may expect that 32 bits builds are still a thing. But after I have went through considerable effort building it on 32 bit ARM I am sure that current Ceph release is not buildable out of the box. Say in options.h Options::size_t (notion of SIZE option) uses std::size_t (largest counter available - 32 bits on 32 bit arches) as store of value. It automatically implies that smoke.sh test which tries to create 100G OSD fails as 100G value just does not fit into 32 bits and trimmed to become just 0 (zero). And the same story with other SIZE options which may exceed 2^32. So clearly Ceph in its current form cannot pass testing on 32 bit systems making me think that 32 bit target was silently dropped at some point.
> >
> > On 22/11/20 7:39 pm, Yuval Lifshitz wrote:
> >
> > I don't know if it is built and tested regularly on 32bit arch, but according to this:
> > https://docs.ceph.com/en/latest/dev/release-process/ <https://docs.ceph.com/en/latest/dev/release-process/>
> > 32bit arch is a valid target for ceph.
> >
> > On Sun, Nov 22, 2020 at 10:30 AM Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> > Hi Yuval,
> >
> >
> >
> > Thank you for pointing me into right direction. I am planning to provide PRs as I already have relevant patches.
> >
> >
> >
> > BTW: am I right in my thinking that Ceph no longer does building and testing on 32 bit architectures?
> >
> >
> >
> > Regards,
> >
> > Vladimir
> >
> > On 22/11/20 7:18 pm, Yuval Lifshitz wrote:
> >
> > Hi Vladimir,
> > We use PRs to github for code contributions to Ceph. For more details see here: [1].
> > If you find issues that need fixing, but you don't plan on fixing right away you can open tracker issues here [2].
> >
> > Yuval
> >
> > [1] https://github.com/ceph/ceph/blob/master/SubmittingPatches.rst <https://github.com/ceph/ceph/blob/master/SubmittingPatches.rst>
> > [2] https://tracker.ceph.com/projects <https://tracker.ceph.com/projects>
> >
> > On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev <vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
> > Hi all,
> >
> >
> > Over last few weeks I was working on making Ceph 15.2.4 to build and run
> > on ARM 32 bit system. It appears that Ceph no longer supports 32 bit
> > systems. But I wanted to run it on Odroid HC-2 which makes a very good
> > cheap OSD basically turning SATA disk into ethernet enabled disk. So I
> > stuck my teeth into getting current Ceph up and running on 32 bit
> > architecture. While doing so I have encountered number of bugs in Ceph
> > codebase which I now want to put back for everyone to use.
> >
> > For example I found a bug in EC code which attempts to malloc around 4GB
> > - this bug is not noticeable on 64 bit systems as malloc happily
> > allocates 4GB but it of course failed on 32 bit system and digging into
> > the issue shown that this malloc was just a bug - it should not be
> > happening at all in the first place.
> >
> > Or wrong include (.cc instead of .h) which caused compilation hard
> > error. Or python threading timeout was specified as int while it should
> > be a float and basically timeout was not happening. And so on. Small
> > inaccuracies peppered around code base. It is certainly should not be
> > done as one huge patch and I am happy to put these patches one by one.
> > But which way it should be done? As number of PR requests on github? Or
> > patch files emailed to someone?
> >
> > May someone from the list enlighten me on acceptable procedure I need to
> > follow?
> >
> >
> > Regards,
> >
> > Vladimir
> > _______________________________________________
> > Dev mailing list -- dev(a)ceph.io <mailto:dev@ceph.io>
> > To unsubscribe send an email to dev-leave(a)ceph.io <mailto:dev-leave@ceph.io>
> >
> > _______________________________________________
> > Dev mailing list -- dev(a)ceph.io <mailto:dev@ceph.io>
> > To unsubscribe send an email to dev-leave(a)ceph.io <mailto:dev-leave@ceph.io>
> >
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
> >
> >
> > _______________________________________________
> > Dev mailing list -- dev(a)ceph.io <mailto:dev@ceph.io>
> > To unsubscribe send an email to dev-leave(a)ceph.io <mailto:dev-leave@ceph.io>
> >
> >
> > _______________________________________________
> > Dev mailing list -- dev(a)ceph.io <mailto:dev@ceph.io>
> > To unsubscribe send an email to dev-leave(a)ceph.io <mailto:dev-leave@ceph.io>
>
>
>
> --
> Regards
> Kefu Chai
There is a general documentation meeting called the "DocuBetter Meeting",
and it is held every two weeks. The next DocuBetter Meeting will be on Nov
26, 2020 at 0200 UTC, and will run for thirty minutes. Everyone with a
documentation-related request or complaint is invited. The meeting will be
held here: https://bluejeans.com/908675367
(Since this particular instance of this meeting will be held on the
Wednesday before United States Thanksgiving, I expect a light turnout.)
Send documentation-related requests and complaints to me by replying to
this email and CCing me at zac.dover(a)gmail.com.
The next DocuBetter meeting is scheduled for:
26 Nov 2020 0200 UTC
Etherpad: https://pad.ceph.com/p/Ceph_Documentation
Meeting: https://bluejeans.com/908675367
Thanks, everyone.
Zac Dover
Hi all,
For placement purposes ceph uses the default straw2 bucket algorithm. I am
curious if the other two bucket algorithms like uniform and list are also
being used in some present use cases in data centers? Are there any use
cases where straw2 is not being used at all ?
BR
Hi all,
Does anyone know how to run "run-cli-tests" in development
environment?
For example:
1. ceph$ ./do_cmake.sh
2. ceph$ cd build
3. build$ make
What's the other steps to run "run-cli-tests"? Does it need to export
some environment variables before running test?
Below PR can't pass "make check" in community's integration system.
It failed at "run-cli-tests". I want to look for the reason to solve
it.
https://github.com/ceph/ceph/pull/37931
B.R.
Changcheng
Hi all,
Over last few weeks I was working on making Ceph 15.2.4 to build and run
on ARM 32 bit system. It appears that Ceph no longer supports 32 bit
systems. But I wanted to run it on Odroid HC-2 which makes a very good
cheap OSD basically turning SATA disk into ethernet enabled disk. So I
stuck my teeth into getting current Ceph up and running on 32 bit
architecture. While doing so I have encountered number of bugs in Ceph
codebase which I now want to put back for everyone to use.
For example I found a bug in EC code which attempts to malloc around 4GB
- this bug is not noticeable on 64 bit systems as malloc happily
allocates 4GB but it of course failed on 32 bit system and digging into
the issue shown that this malloc was just a bug - it should not be
happening at all in the first place.
Or wrong include (.cc instead of .h) which caused compilation hard
error. Or python threading timeout was specified as int while it should
be a float and basically timeout was not happening. And so on. Small
inaccuracies peppered around code base. It is certainly should not be
done as one huge patch and I am happy to put these patches one by one.
But which way it should be done? As number of PR requests on github? Or
patch files emailed to someone?
May someone from the list enlighten me on acceptable procedure I need to
follow?
Regards,
Vladimir
This is a short point release to include 3 PRs on top of 14.2.14 point release.
Details of this release summarized here:
https://tracker.ceph.com/issues/48299#note-1
Only rados and ceph-volume are to be re-tested. Please speak up if
this is a wrong plan!
rados - progress
ceph-volume - Jan, Sebastian approved ?
Thx
YuriW
Any hints as to why https://github.com/ceph/ceph/pull/37933 is failing one of the tests after I rebased it? So far I haven't succeeded in getting the tests to run locally.
Mark Houghton
