[LU-6766] add support for arm64

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.8.0
• Affects Version/s: Lustre 2.7.0
• Labels: patch
• Environment: arm64
• Assignee: WC Triage
• Reporter: Arnaud Guignard

Description

Expand lustre to support the ARM64 platform.

A first patch will be submitted shortly to enable basic compilation:

• the architecture is reported as aarch64 so add that support to lustre-build-linux.m4,
• for the Red Hat/Fedora packaging, strip the aarch64 suffix for the required kernel,
• add definitions for lstat_t, lstat_f, fstat_f and fstatat_f for aarch64 architecture in lustre/include/lustre/lustre_user.h.

Moreover, the SYS_chown syscall is not available on arm64 (because as __ARCH_WANT_SYSCALL_NO_AT is not defined, __NR_chown is not defined in /usr/include/asm-generic/unistd.h). So the following call in lustre/utils/liblustreapi.c must be modified:

/* libc chown() will do extra check, and if the real owner is

• the same as the ones to set, it won't fall into kernel, so
• invoke syscall directly. */
  rc = syscall(SYS_chown, path, -1, -1);

This leaves several options:

• the code dates back to 2007, glibc has evolved since then and it can be replaced with `chown()`.
• replace it with `syscall(SYS_openat, ...)` and `syscall(SYS_fchownat, ...)`.
• add `#ifdef _aarch64_` and a call to `chown()`.

Does someone more qualified have an opinion?

Issue Links

• is related to: LU-11200 Centos 8 arm64 server support
• is related to: LU-11832 ARM servers crashing on MDS startup
• is related to: LU-4199 Lustre client support for ARM platform

Comments

[Joseph Gmitter (Inactive)]

Landed for 2.8.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/15395/
Subject: LU-6766 build: add support for arm64
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 79ec8eaa7b83e522f754bc685110915ad216e548

[Peter Jones]

Aurelien

It is still possible for this patch to make 2.8. The FixVersion change reflects that code freeze is approaching and the remaining fix is not critical to include. As I understand it, communication has been sent directly to CEA outside of this ticket about this remaining patch. As you have sent me a note directly, let's work out these details on that thread and then re-post hear when we have reached a conclusion.

Thanks

Peter

[Aurelien Degremont (Inactive)]

This was just moved to 2.9 as the code freeze is approaching I assume.
However this patch and fix for this ticket is very ready for a while now without any issue at all.

I disappointed this patch is going to miss this window as it was ready for a while and it has only green lights and nobody really raised an problem...

[Aurelien Degremont (Inactive)]

Only one of the 2 patches for this ticket is landed.

http://review.whamcloud.com/#/c/15395/ has all green lights and 3x "+1" (2 from Intel devs and 1 from James Simmons).

Is there any reason I missed preventing this 7-line patch from landing?