Re: Survey: Is anyone using 32-bit builds of the CephFS kernel client?
Xiubo Li <[email protected]>
| Newsgroups | org.kernel.vger.ceph-devel |
|---|---|
| Message-ID | <CAOJNxR+XiUxR1GNUgd8T18x2KH8kstWtpxwL-mwwE0i_qospJA@mail.gmail.com> |
Hi everyone, Thanks for the feedback. So far, I have received several replies regarding the 32-bit CephFS kernel client usage. Based on the responses, there do not appear to be any active users of 32-bit builds, and I have not received any objections to moving forward with a 64-bit-only implementation. Therefore, I will continue working on the patch to remove 32-bit support and proceed with the 64-bit-only approach. I will make sure the change is properly documented, including the deprecation/removal of 32-bit support in the relevant release notes. Thanks again for the feedback and discussion. Best regards, Xiubo On Thu, 16 Jul 2026 at 16:53, Xiubo Li <[email protected]> wrote: > > Hi everyone, > > We are considering a performance improvement for the CephFS kernel > client (kclient) that would be significantly simpler and cleaner to > implement as 64-bit-only. Supporting 32-bit in this case adds > non-trivial complexity and ongoing maintenance burden, so we'd like to > understand whether continuing 32-bit support is still necessary. > > Before making any decision, we want to hear from the community: > > - Are you currently using, or planning to use, 32-bit (arm/armhf, > i386/i686) builds of the CephFS kernel client? > - If yes, is this for production workloads? Or legacy/testing purposes? > - What is your platform (distribution, kernel version, architecture)? > > If there are no active 32-bit users, we would proceed with a > 64-bit-only implementation and clearly document the deprecation in the > release notes with appropriate warnings. > > If 32-bit support is still needed, we will explore alternative > approaches — for example, keeping the current code path for 32-bit > while the new fast path is 64-bit-only, or finding a way to cleanly > abstract the difference. > > Please reply by August 6, 2026 so we can factor your feedback into the plan. > > Thanks! > Xiubo Li