Details
-
New Feature
-
Resolution: Fixed
-
Minor
-
Lustre 2.9.0
-
Ubuntu 14.04.5 with Backport Kernel 4.4.0 from Ubuntu 16.04
-
9223372036854775807
Description
Currently, only SuSE or RedHat machines can be used as Lustre servers. Ubuntu can only be used as a Client.
Since Lustre has recently started supporting SLES12 with Kernel 4.4.0 – the very same version used by Ubuntu 16.04 (and 14.04. via HWE Kernels), we had the idea of porting Lustre over (since our future usage of Lustre would greatly benefit from that).
We made good progress in that respect and have adjusted the Kernel-Patches for "ldiskfs" to also work for Ubuntu's flavour of Kernel 4.4.0. Additionally, we have extended the Debian build system provided by Lustre, to be able to create both client and server tools and modules.
You can find the patches against Lustre 2.9.57 attached to this ticket. The kernel patches target version 4.4.0-45.66.
The compilation and creation of the packages works well and produces the needed modules and tools. Both debian packages install cleanly and the modules (lnet, ldiskfs, lustre) load correctly.
Unfortunately, once we come to the creation of the Lustre file system, we run into a curious error:
root@musxbeo050:~# mkfs.lustre --mgs --mdt --fsname=lustre --backfstype=ldiskfs --index=0 /dev/sda7 mkfs.lustre FATAL: unhandled/unloaded fs type 1 'ldiskfs' mkfs.lustre FATAL: unable to prepare backend (22) mkfs.lustre: exiting with 22 (Invalid argument)
This is despite the fact, that "ldiskfs" is properly registered with the kernel:
root@musxbeo050:~# uname -a
Linux musxbeo050 4.4.0-45-generic #66~14.04.1lustre SMP Mon May 8 18:23:05 CEST 2017 x86_64 x86_64 x86_64 GNU/Linux
root@musxbeo050:~# grep "ldiskfs\|lustre" /proc/filesystems
ldiskfs
lustre
The only unusual message in the kernel log is a complaint by the "ldiskfs" module, that it cant' register itself under the "ext3" alias.
May 26 14:16:11 musxbeo050 kernel: [159891.600363] LDISKFS-fs: Unable to register as ext3 (-16)
So far, we have not yet tested the ZFS backend, but since no kernel changes are needed for that one at all, we don't think that it will be a great issue, once this one is solved.
Thanks!
