I don't know if it is built and tested regularly on 32bit arch, but
according to this:
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
>
>