Skip to main content

Supported operating systems

MooseFS runs on POSIX-compliant operating systems. Official support covers a named list. The list changes from release to release. In 5.2.0, the list contains:

  • Ubuntu
  • Debian
  • Red Hat Enterprise Linux (RHEL) and CentOS
  • Rocky Linux and AlmaLinux
  • Fedora
  • openSUSE
  • Arch Linux
  • Alpine Linux
  • FreeBSD
  • macOS

A system on the list runs MooseFS whether or not a package is built for that particular system. Where no such package exists, the package of a compatible system is installed instead. .rpm packages are compatible with openSUSE Leap. .deb packages are compatible with Proxmox, which the list does not name at all. Fedora 44 has packages of its own.

Bare metal, VMs, and containers covers a separate decision: whether such a system runs on hardware of its own, in a virtual machine, or in a container. A client machine also needs FUSE (Filesystem in Userspace) on top of the operating system. Planning client machines covers what FUSE requires of the platform.

Packages are built for four processor architectures​

The packages are built for i386 and amd64 on x86, and for armhf and arm64 on ARM, so both word sizes are covered on both families. The MooseFS download page lists which releases of which system have a package for each of the four architectures. That pairing changes as systems are released and retired.

Packages are sometimes still built for a system after its support ends, so that installations already running on that system can still be upgraded. Such a package is used at your own risk. On that system, a problem is not investigated if it could have come from the operating system or its kernel rather than from MooseFS alone. CentOS 6 is one such system. Packages are still built for it, but the system is no longer supported.

A system with no package of its own is not out of reach. The sources of the Community Edition build on POSIX-compliant systems generally. A system where the sources do not build is treated as something to fix in the code rather than as a system out of scope. Such fixes have been made for distributions that no package is built for. MooseFS PRO is binary only, so a source build is possible in the Community Edition alone.

Both editions ship as packages, Community Edition also as source​

Packages come in the format native to the platform: .deb, .rpm, or .pkg. The names of the packages are covered under package names. The source code of the Community Edition is public and can be compiled on compatible POSIX platforms. MooseFS PRO is distributed in binary form only, for the supported systems.

Support follows the system, not the component​

A supported system runs every component: the Master Server, the Chunkservers, the Metaloggers, and the clients alike. No component stops one release earlier than the others. Two libraries set per-module limits: a mount needs FUSE 3, and the GUI and mfscli need Python 3.4 or newer. Both libraries belong to the system rather than to MooseFS. A system without one of them still runs everything else. Two components are more limited than the rest. mfsbdev is built on Linux alone (block device operations). mfsnetdump needs the packet capture library.

Word size follows the same rule. A 32-bit system is supported wherever the system itself still ships in a 32-bit variant, back to the oldest release that packages are built for. MooseFS 5.x has 32-bit builds. Where a system stops shipping that variant, its later releases are 64-bit, and so is the support for them. An instance that mixes 32-bit and 64-bit machines is supported as well. Report a problem that comes from the mixing alone and from MooseFS alone.

Prefer 64-bit systems and stable LTS releases​

Support is not a recommendation. Choose 64-bit systems and current releases of them wherever there is a choice, because newer kernels include optimizations that older kernels do not. Performance, scalability, and long-term compatibility all favor 64-bit systems and current releases of them. A 32-bit system is limited by the memory that it can address. The limit barely shows on a small installation at home but matters on a commercial installation. There, the address space limits the metadata the Master Server holds in RAM. Choose stable LTS (Long Term Support) releases of the chosen distribution, for compatibility and security.

A source build needs a GNU toolchain and zlib​

A build from source needs a standard GNU toolchain and the zlib development library. The Master Server and the Chunkserver do not build without the zlib development library. The other libraries decide which components the build produces rather than whether the build runs at all. Without the FUSE development files, the mount is skipped. Without the packet capture library, mfsnetdump is skipped as well. Without Python 3, the GUI and the CLI are skipped. Any machine that is meant to serve the GUI or run the CLI needs Python 3, however MooseFS was installed. A source build also decides some defaults that the packages otherwise set for you. See values set at build time.