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.