A Year in Releases: 2024
MooseFS moved from 4.53.0 to 4.57.x this year. Most of it was routine, but three changes stand out. Storage classes now have more control over their four states. Master Servers can keep serving reads even when a location gets cut off. And the Web GUI looks different from how it did before.
Storage classes can now set a label mode per state
Before 4.53.0, a Storage Class used one label mode for its whole lifecycle, from creation to trash. That release let you override the mode for each state instead, CREATE, KEEP, ARCHIVE, and TRASH. So a class could run STRICT while chunks sit in KEEP, then fall back to LOOSE once they move to ARCHIVE.
The same release also changed how Chunkserver IP addresses get remapped. The old REMAP option, in the Master Server configuration, could only substitute a fixed prefix, and only when the address suffixes already matched. A separate configuration file, csipmap.cfg, arrived in 4.53.0 and lets an administrator map Chunkserver IP numbers however they need, with no suffix restriction.
A Master Server gained a read-only state for lost connections
In 4.55.0, PRO’s Master Server picked up a new state called DEPUTY. Normally a Master Server sits in ELECT when it can’t reach LEADER, because fewer than half its Chunkservers are connected. Now, instead of waiting indefinitely, it can move into DEPUTY. Once there, it keeps serving data in read-only mode.
The state is meant for instances split across more than one physical location, different server rooms, or different cities. Losing the link between locations used to leave one side without a working Master Server at all. Only one Master Server can still become LEADER and touch the cluster’s metadata, so a DEPUTY doesn’t cause a split brain. It can’t take writes until the connection comes back.
Modules now check they agree on the Master Server
A consistency check added in 4.56.0 now runs across every module in an instance. Each module now checks whether it sees the same Master Server IP as everyone else. In the Community Edition that means a single address. In PRO it means the same list of addresses, since more than one Master Server can be configured there. PRO goes a step further and checks the configuration of all Master Server modules against each other too. Any mismatch gets logged, either by the Master Server itself or by the LEADER in a PRO instance.
The Web GUI got a new look
The Web GUI was reworked in 4.56.3, changing how the interface looks. PRO matched that look shortly after. The redesign kept moving through the patches that followed. 4.56.4 added auto-refresh and color themes on top of the new layout. 4.56.5 turned some of the interface’s navigation links into knobs, the switch-style controls that narrow a view without leaving the page. And 4.56.6 cleaned up CLI bugs that the new GUI features had introduced along the way.
Storage class priority replaced two outdated options
The biggest change to Storage Classes since 4.53.0 landed in 4.57.0. A snapshot can leave a chunk belonging to files in more than one class at once. Until this release, the Master Server picked a predefined class for that shared chunk, ignoring the classes actually assigned to it. Now each class definition carries a priority number, and a shared chunk is governed by whichever of its classes ranks highest.
The mingoal and maxgoal options in exports.cfg used to limit which storage goals a mount could use, but they stopped making sense once clusters moved from numeric goals to Storage Classes entirely. Export groups replaced them in 4.57.0. Each Storage Class now belongs to one of sixteen groups, numbered 0 to 15 with 0 as the default, and a mountpoint can be restricted to specific groups. The predefined classes a fresh instance ships with changed too. A new instance now defines four of them in the Community Edition and six in PRO, and unlike the ones they replaced, every one of them can be edited or deleted.
Further reading
What a fresh instance defines by default, in both editions, is covered in Storage Classes.