MooseFS Files

This is a maintenance release focused on improving master-to-master timeout handling, fixing client-side read-ahead behavior, and correcting minor typos.

Master

• Changed timeouts used in master-to-master connections (Pro only)
  Handling of timeouts between Master and Follower processes has been improved.

Previously, when the Master used a large amount of RAM (around 500 GiB), the fork operation (used for metadata writes or replication to Followers) could take longer than 10 seconds, which caused failures because the metadata fetch module had a hardcoded 10 second limit.

Changes include:

• Unified variable naming: MATOMA_TIMEOUT now replaces MASTER_TIMEOUT in Master configuration, consistent with other timeout variables.
• The metadata download module now respects configured timeout values.
• The leader measures fork duration and, if it takes too long, instructs Followers to use a higher timeout automatically.
  This prevents timeout errors during metadata synchronization, even when MATOMA_TIMEOUT is set too low.

Important Upgrade Recommendation

We strongly recommend upgrading for all users running Master instances that use large amounts of memory (around 500 GiB or more). Older versions carry a risk that, if a follower becomes desynchronized for any reason, it may fail to resynchronize due to timeout loops. In such cases, recovery would require an emergency upgrade instead of a planned one.

To ensure a smooth upgrade:

1. Follow the standard upgrade procedure, starting with Followers.
2. Before upgrading Followers, set the config variable MATOMA_TIMEOUT to a value higher than 10 seconds (e.g., 30 seconds is very safe).
3. After upgrading the leader, you may reduce the timeout again (e.g., back to 10 seconds) and monitor logs.
4. If log messages indicate that a fork takes longer than the timeout, increase it as suggested in the logs.

Note: The old leader version does not automatically enforce longer timeouts, so manually increasing MATOMA_TIMEOUT during the upgrade is essential.

Client

• Fixed test for overlapping requests in the read-ahead algorithm
  (Pull request by @chuandew)

A typo in a variable might have caused overlapping chunk reads in the read-ahead cache. While it worked correctly, the behavior was slightly inefficient. The fix ensures that overlapping reads are avoided and the cache now behaves as originally intended.

All

• Fixed typos and spelling errors
  Various minor textual corrections contributed by community members, especially @onlyjob and @tianon).