Best way to contribute bunch of miscellaneous fixes?

List overview All Threads
Download

newer

older

run run-cli-tests in development...

14.2.15 (short) Nautilus...

Vladimir Bashkirtsev

22 Nov 2020 22 Nov '20

6:44 a.m.

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

Show replies by date

Yuval Lifshitz

22 Nov 22 Nov

11:18 a.m.

...

Vladimir Bashkirtsev

11:29 a.m.

...

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>

Yuval Lifshitz

11:39 a.m.

...

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 [2] https://tracker.ceph.com/projects On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev < vladimir(a)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 > To unsubscribe send an email to dev-leave(a)ceph.io > >

Vladimir Bashkirtsev

11:48 a.m.

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> >

Duncan Bellamy

8:01 p.m.

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> 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/ 32bit arch is a valid target for ceph. On Sun, Nov 22, 2020 at 10:30 AM Vladimir Bashkirtsev <vladimir(a)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 >> [2] https://tracker.ceph.com/projects >> >> On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev <vladimir(a)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 >>> To unsubscribe send an email to dev-leave(a)ceph.io >>>

_______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io

Vladimir Bashkirtsev

23 Nov 23 Nov

2:18 a.m.

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> 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> 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/ > 32bit arch is a valid target for ceph. > > On Sun, Nov 22, 2020 at 10:30 AM Vladimir Bashkirtsev

<vladimir(a)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 >>> [2] https://tracker.ceph.com/projects >>> >>> On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev

<vladimir(a)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

>>>> 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 >>>>> To unsubscribe send an email to dev-leave(a)ceph.io >>>>> > _______________________________________________ > Dev mailing list -- dev(a)ceph.io > To unsubscribe send an email to dev-leave(a)ceph.io

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Duncan Bellamy

11:37 a.m.

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> 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

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 To unsubscribe send an email to dev-leave(a)ceph.io

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Vladimir Bashkirtsev

11:48 a.m.

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:

...

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 todev-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.

Duncan Bellamy

3:09 p.m.

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.debian.tar.xz>

...

On 23 Nov 2020, at 08:48, Vladimir Bashkirtsev <vladimir(a)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 > > 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> 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> 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> 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/ >>>> 32bit arch is a valid target for ceph. >>>> >>>> On Sun, Nov 22, 2020 at 10:30 AM Vladimir Bashkirtsev <vladimir(a)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 >>>>> [2] https://tracker.ceph.com/projects >>>>> >>>>> On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev <vladimir(a)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 >>>>> To unsubscribe send an email to dev-leave(a)ceph.io >>>>> >>> _______________________________________________ >>> Dev mailing list -- dev(a)ceph.io >>> To unsubscribe send an email to dev-leave(a)ceph.io >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >

Vladimir Bashkirtsev

3:20 p.m.

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:

...

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> 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> 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> 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/ >>>> 32bit arch is a valid target for ceph. >>>> >>>> On Sun, Nov 22, 2020 at 10:30 AM Vladimir >>>> Bashkirtsev <vladimir(a)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 >>>>> [2] https://tracker.ceph.com/projects >>>>> >>>>> On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev >>>>> <vladimir(a)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 >>>>> To unsubscribe send an email to dev-leave(a)ceph.io >>>>> >>> _______________________________________________ >>> Dev mailing list -- dev(a)ceph.io >>> To unsubscribe send an email to dev-leave(a)ceph.io >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >

Duncan Bellamy

3:33 p.m.

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> 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:

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 To unsubscribe send an email to dev-leave(a)ceph.io

kefu chai

24 Nov 24 Nov

11:50 a.m.

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> 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> 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… On 23 Nov 2020, at 08:48, Vladimir Bashkirtsev <vladimir(a)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 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> 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> 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> 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/ 32bit arch is a valid target for ceph. On Sun, Nov 22, 2020 at 10:30 AM Vladimir Bashkirtsev <vladimir(a)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 [2] https://tracker.ceph.com/projects On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev <vladimir(a)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 To unsubscribe send an email to dev-leave(a)ceph.io _______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io _______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io

-- Regards Kefu Chai

1257

days inactive

1259

days old

dev@ceph.io

Manage subscription

12 comments

4 participants

tags (0)

participants (4)

Duncan Bellamy
kefu chai
Vladimir Bashkirtsev
Yuval Lifshitz